Home / server / Questions / 893112
Accepted
leonbloy
Asked: 2018-01-20 11:24:27 +0800 CST

Migrating from iptables to firewalld : commenting rules

  • 772

I'm migrating from iptables to firewalld, using Centos 7. In the old times, I used to write the (permament) iptables rules in the /etc/sysconfig/iptables , which also served to place comments prepended by # (to remind us why we restricted this or that ip, etc).

Now, it seems that the current (permanent) configuration is read from /etc/firewalld/ files (especially /etc/firewalld/zones/*.xml). I guess I could add xml comments there, but it seems the good practice is not to edit those files directly but via firewall-cmd (no?).

Hence, I'm not sure which is the standard or recommended way to add comments to the rules.

Any suggestions?

Edited: For the record, I've verified that xml comments do not survive firewall-cmd modifications.

linux

3 Answers

  1. As of 2/2020, I think firewalld use sufficiently widespread that ease of annotating rules either from firewall-cmd or from firewall-config is very important, for reasons discussed in the OP.

    Suggestions that we document rules in a CMS, via firewall-cmd --direct, via ipsets, or edit zone files manually, all complicate management and defeat a purpose of firewalld, that of making firewall configuration more transparent.

    Therefore, until firewall-cmd --comment becomes available, I will annotate my rules via the log prefix option to firewall-cmd --add-rich-rule. For example,

    firewall-cmd --add-rich-rule="rule family=ipv4 source address=192.168.103.225 reject log prefix='Onsite NIDS'"
firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=192.168.103.225 reject log prefix='Onsite NIDS'"

    The resulting annotation appears in my system log as a side-effect, but now output of firewall-cmd --list-all-zones is self-documenting:

    public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens160
  sources:
  services: dhcpv6-client http https ssh
  ports: 1515/tcp 1514/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" source address="192.168.103.225" log prefix="Onsite NIDS" reject

    The comment is also recorded in my zone file as:

    # cat /etc/firewalld/zones/public.xml
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="dhcpv6-client"/>
  <service name="http"/>
  <service name="https"/>
  <port protocol="tcp" port="1515"/>
  <port protocol="tcp" port="1514"/>
  <rule family="ipv4">
    <source address="192.168.103.225"/>
    <log prefix="Onsite NIDS"/>
    <reject/>
  </rule>
</zone>

    I realize that even this approach overly complicates configuration by introducing rich rules, but believe the benefit in annotation worthwhile for now.

    • 2

  2. Although in the firewall-cmd man page, there is a section on Direct Options, that allow you to give parameters, so you could do something like:

    firewall-cmd --direct --add-rule <table> <chain> <priority> <args> -c <some comment>

    Although, as Michael Hampton said, probably not the best thing.

    • 1
  3. Best Answer

    Thinking it over, I'm finding this firewalld-cmd thing slightly silly. After all, XML configuration files are human editable. It makes little sense to me, having to learn an extra layer of commands (well, one command, but with tons of arguments) only to edit some simple and neat XML files (*).

    I fell slightly stupid typing

    firewall-cmd --permanent --zone=work --add-port=445/tcp

    just for addding the following line to /etc/firewalld/zones/work.xml

    <port protocol="tcp" port="445"/>

    Hence, at least for now, and considering that the XML elements don't include comment attributes (there are some requests in that direction) I'm leaning towards the following strategy: just forget about firewalld-cmd (perhaps even delete it), edit the XML files yourself, and add XML comments freely.

    (*) It's true that firewalld-cmd allows also to add dynamic (non permanent) rules. But I'd bet that that is not a very frequent scenario.

    • 1