Início / unix / Perguntas / 497697
Accepted
sourcejedi
Asked: 2019-01-31 05:15:07 +0800 CST

firewall-cmd diz que nenhuma zona de firewall está ativa. Por quê?

  • 772

No Debian 9, instalei firewalld(versão 0.4.4.2-1).

sudo firewall-cmd --get-active-zonesnão mostra saída. E echo $?mostra que o status de saída era 0 ( EXIT_SUCCESS). Por quê?

Eu tenho uma interface de rede eth0, que é mostrada por ip link(assim como a interface de loopback lo).

Devo dizer que minha configuração de firewall parece estar funcionando principalmente. FWIW, alterei a zona padrão de publicpara MyZone, definida da seguinte forma:

$ 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>

Se eu tentar me conectar usando outro computador, terei permissão para acessar os serviços SSH e HTTPS. E se eu rodar ncat -l -p 8000no servidor, e tentar conectar com ncat my-server 8000, a conexão é bloqueada corretamente. ( Ncat: No route to host. E tcpdumpmostra que uma resposta inacessível ICMP é gerada, digite "admin proibido").

Por que firewall-cmd --get-active-zonesnão está mostrando MyZone como ativo?

$ 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.servicenão registra nenhum aviso.

$ 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.

Vejo que firewalldprefere ser usado com o NetworkManager. Não estou executando o NetworkManager no momento, e parece que isso é um pouco frágil.

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

Se o NetworkManager não for usado, existem algumas limitações... Se o firewalld for iniciado depois que a rede já estiver ativa, as conexões e as interfaces criadas manualmente não serão vinculadas a uma zona.

No entanto, reiniciei pelo menos uma vez desde a instalação do firewalld. Verifiquei o systemdserviço. firewalld.serviceé iniciado Before=network-pre.target. networking.serviceé iniciado After=network-pre.target. Eu confirmei que firewalldé iniciado antes 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.

Não reiniciei manualmente a rede ou executei ifdown/ ifupe não estou executando ifplugd. Os logs do kernel (abaixo) dizem que o link ethernet está ativo e o IPv6 está em execução continuamente desde a inicialização.

$ 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

Eu nem estou usando DHCP. A configuração para 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
debian firewalld

2 respostas

  1. Best Answer

    firewalld não depende do NetworkManager, mas o uso é recomendado .

    Eles não estão brincando.

    Na ausência do NetworkManager, o documento da página da Web continua dizendo que você deve duplicar/manter a consistência entre a configuração em dois locais diferentes.

    Além disso, o primeiro dos dois lugares é o ifcfgsistema de configuração de rede, que não existe no Debian. Por implicação, o NetworkManager é necessário no Debian :-).

    (Sintetizando várias informações, fica claro que a configuração duplicada em /etc/firewalld/, é necessária apenas no caso de você iniciar manualmente firewalldapós a interface de rede ter sido iniciada. Isso inclui se você reiniciar firewalld, embora normalmente prefira não reiniciar firewalld.)

    Por um lado, provavelmente é justo esperar o comportamento específico "principalmente trabalhando" que foi observado na pergunta. Com base em outra documentação e observações adicionais, você pode esperar que a zona padrão seja aplicada à(s) sua(s) interface(s).

    No Debian sem NetworkManager, atribuir uma interface a uma zona diferente provavelmente parecerá funcionar no sistema em execução, mas não funcionará quando você reiniciar.

    Você pode querer ter mais do que "expectativas razoáveis" para seu firewall. É mais reconfortante se você puder usar a configuração "recomendada", que provavelmente obtém melhores testes quando firewalldalterada, e não precisa confiar em um comportamento tão confuso.

    E continuo confuso com as implicações disso, inclusive para os sistemas Red Hat. É extremamente confuso que firewall-cmd --permanent --add-interface=...possa mostrar literalmente o resultado " success", quando não conseguiu salvar a configuração da zona corretamente!

    Aqui está a citação relevante em man firewalld:

    Se o NetworkManager não estiver em uso e o firewalld for iniciado depois que a rede já estiver ativa, as conexões e as interfaces criadas manualmente não serão vinculadas à zona especificada no arquivo ifcfg. As interfaces serão tratadas automaticamente pela zona padrão. firewalld também não será notificado sobre renomeações de dispositivos de rede. Tudo isso também se aplica a interfaces que não são controladas pelo NetworkManager se NM_CONTROLLED=noestiver definido.

    Você pode adicionar essas interfaces a uma zona com

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

    Se houver um /etc/sysconfig/network-scripts/ifcfg-interfacearquivo, o firewalld tentará alterar a ZONE=zoneconfiguração nesse arquivo.

    Se o firewalld for recarregado, ele restaurará as ligações de interface que estavam em vigor antes do recarregamento para manter as ligações de interface estáveis ​​no caso de interfaces não controladas do NetworkManager. Esse mecanismo não é possível no caso de uma reinicialização do serviço firewalld.

    É essencial manter a ZONE=configuração no arquivo ifcfg consistente com a ligação no firewalld no caso de interfaces não controladas do NetworkManager.

    Como experimento, tentei o comando mencionado:

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

    Esse comportamento é o que você esperaria da documentação se minha interface de rede tivesse sido iniciada após o firewalld. No entanto, minha interface de rede não foi iniciada após o firewalld.

    A manpágina faz parecer que firewallddepende de obter retornos de chamada ifcfgquando inicia uma interface de rede. No entanto ifcfg, é o sistema de rede da Red Hat; ele não está instalado no meu sistema Debian. Parece que o firewalldpacote Debian não fornece nenhum equivalente. Portanto, degradamos para "as interfaces serão tratadas automaticamente pela zona padrão".

    Corri sudo iptables-savepara ver as regras do iptables (somente IPv4) geradas pelo firewalld. Se eu não tiver executado manualmente firewall-cmd --add-interface..., não há menção ao eth0. Mas se eu ler corretamente, as regras tratam tais pacotes usando as regras da zona padrão, como um fallback.

    • 2

  2. Se você não colocou nenhum arquivo de configuração em /usr/lib/firewalld/zonesou /etc/firewalld/zonesvocê não tem nenhuma zona configurada. Tudo que você teria é um firewall genérico. Ainda é eficaz dependendo das regras que você possui, apenas não há como alternar de público para privado ou qualquer outra zona que você possa ter configurado e fazer com que as regras sejam alteradas automaticamente.

    Além disso, se você usou uma GUI para configurar o firewall, apenas verifique esses diretórios para garantir que as configurações que você definiu foram realmente implementadas.

    Se você colocar manualmente os arquivos de configuração lá ou o gerenciador de configurações da GUI colocar com êxito os arquivos para as zonas que você configurou, não tenho ideia.

    firewalld é uma ferramenta de gerenciamento de firewall para sistemas operacionais Linux. Ele fornece recursos de firewall atuando como um front-end para o framework netfilter do kernel Linux através do comando iptables, atuando como uma alternativa ao serviço iptables

    Verifique: iptables -S, o que há? Se houver regras listadas, é um firewall genérico! Você não precisa de firewalld para ter um firewall, você pode editar manualmente o iptables.

    Em seguida, instale iptables-persistente salve suas regras após cada edição comnetfilter-persistent save

    A política padrão na maioria dos sistemas é (PUBLIC):

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

    Então você pode elaborar com regras na forma de cadeias.

    • Sintaxe:

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

    Exemplo: (permitir todo o SSH de entrada na porta padrão não é uma boa prática para segurança)

    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
    • 0

relate perguntas