7

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.

leonbloy
  • 2,118
  • 17
  • 23
  • As a general rule, you don't. What are you trying to accomplish with comments? There may be a better way to reach the end goal, whatever it is. – Michael Hampton Jan 19 '18 at 19:48
  • 2
    I gave an example: I block an ip (place it inside a drop zone) and I want to remind me why. Also, I add acces to a non-standard tcp port that I use for a test service, etc. The general point is maintenance. – leonbloy Jan 19 '18 at 19:51
  • OK, that does make sense. Though such comments are probably better suited for your configuration management system. – Michael Hampton Jan 19 '18 at 20:24
  • 2
    another example: allow users to see current firewall rules on a server with comments - if on the server they can easily see settings and related comments instead of having to go someplace else to get that info (useful for devs and devops) – user12345 Sep 08 '18 at 00:55

3 Answers3

2

As of 10/2022, 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 --permanent --add-rich-rule="rule family=ipv4 source address=192.168.103.224 reject log prefix='Onsite NIDS 1'"
firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=192.168.103.225 reject log prefix='Onsite NIDS 2'"

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.224" log prefix="Onsite NIDS 1" reject
        rule family="ipv4" source address="192.168.103.225" log prefix="Onsite NIDS 2" 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.224"/>
    <log prefix="Onsite NIDS 1"/>
    <reject/>
  </rule>
  <rule family="ipv4">
    <source address="192.168.103.225"/>
    <log prefix="Onsite NIDS 2"/>
    <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.

CODE-REaD
  • 223
  • 2
  • 9
  • 1
    If one uses the "log prefix" workaround as shown above, is there a potential concern for performance? Wondering if I were to use this for opening a port on something like a home/remote server that's maintaining an active connection, if the system would be generating more log statements about the connection. Probably wouldn't be a big deal for a file server but something like a game server or a mumble server where there are long-ish active connections even with a small number of users (<5), I'm not sure. Any clues? – zpangwin Apr 03 '22 at 20:56
  • @zpangwin: Especially when relevant logs are written to a disk, there can be performance concerns. – Smar Jun 26 '22 at 04:26
2

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.

leonbloy
  • 2,118
  • 17
  • 23
  • you could also just stick to iptables by [removing firewalld and installing iptables](https://www.digitalocean.com/community/tutorials/how-to-migrate-from-firewalld-to-iptables-on-centos-7) – user12345 Sep 08 '18 at 01:02
  • 1
    @user12345 Sure. I just try to become familiar with these new things, especially if they became more or less standard. – leonbloy Sep 08 '18 at 01:26
1

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.

lsd
  • 1,673
  • 10
  • 10