C7, Firewalld And Rich Rules

Home » CentOS » C7, Firewalld And Rich Rules
CentOS 11 Comments

Hi, again, folks,

I’m trying to convert a number of iptables rules to firewalld rich rules. I need to do this, because this is, in fact, a firewall, to protect access to servers with sensitive data. It will limit access to the servers behind it to a specific network, and nobody else, and allow only certain services through.

What I’ve been trying to find is a script/program that converts the output of iptables-save to something I can feed to firewall-cmd. Anyone have a link to such?

I admit this is annoying. Why is it, when some New Kewl thing is introduced, it *always* expects you to start anew, rather than giving you a tool to convert what you had. I ran into this 15 years ago, trying to put an existing website into bricolage (early CMS), and here I am, trying to do this.

Anyway, any links would be appreciated.

mark

11 thoughts on - C7, Firewalld And Rich Rules

  • None that I know of.  It might be easier for you to convert existing rules to “direct” rules than “rich” rules.

  • shorewall doesn’t support nftables, which is largely the point of firewalld:  The Linux firewall system is currently undergoing yet another deprecation and migration from iptables to nftables. firewalld should remain stable during the migration process.  As far as I know, there are no plans to support nftables under shorewall, so new users will most likely throw away any investment they make in learning and implementing shorewall.

  • IIRC nftables has a compatibility mode with iptables?

    Anyway, I thought the future on Linux is bpfilter, no?

    Until then, I’ll continue to enjoy Shorewall as I did for more a decade now.

    Regards, Simon

  • Gordon Messmer wrote:
    a) I’m at work. I have to do what is required.
    b) we are moving from iptables to firewalld. No other options.

    Since the firewall system is moving from iptables to firewalld, WHY IS
    THERE NOT A PROGRAM INCLUDED with the firewalld package to convert EXISTING rules?

    Each firewall will have its own set of rules. We have three? four?
    internal firewalls, *each* with its own rules. Since that’s us, I assume there are tens, if not hundreds of thousands just like us, many with more firewalls.

    Why would *ANYONE* think that everyone should just start from scratch, taking all the time in the world to get it converted?

    mark, still looking for a script

  • You answered your own question. Because a lot of different places set up their firewalls their own way and parsing all the different ones/ways seems to break over and over again? Firewalld is still outputting text in iptables format.. and will output it in nftables later when it is done. It is just a program which tries to make decisions which certain classes of systems need to be done automagically.

    For most RHEL-7 systems which have custom iptables rules.. I thought the package iptables-services.x86_64 sets up everything to keep that going. If you need to move to firewalld because it should support future formats (
    nftables, plughtables, xyzzytables, etc.) you are going to need to learn the tool just like you had to from ipchains to iptables days. [Pretty much every conversion tool from ipchains to iptables worked only on the simplest but anyone with a custom firewall ended up having to learn the syntax.]

  • If the conversion were simple enough to be easily automated, the new system is probably no more than just a syntactic difference away from the old, and thus does not provide any interesting new functionality or change in existing functionality.

    It’s much the same as asking why there aren’t automatic programming language conversion tools: we wouldn’t need more than one programming language if they all mapped 1:1 to each other, short of going down to the machine code level and back up the technology stack.

    Pretty much all the other major competing OSes have had at least one incompatible shift in their firewall implementations over the years, even that supposed bastion of ultimate stability, FreeBSD. I take that as a sign that those designing firewall schemes in the early 1990s didn’t have magical levels of foresight when doing their work, so that replacements had to be incompatible to provide the functionality we now expect.

  • Ok, I’ve found something that will work – adding –direct rules. That, I
    can do via iptables-save | a 10-line awk script.

    A question, though: in iptables, we’ve got INPUT and FORWARD defined as using the same chain. Is there a way to do that with firewalld – it’s not clear from what I’m reading.

    Once I have this working, I’m going to investigate if I can export them as rich rules, so in the new format.

    mark

  • Warren Young wrote:

    Note that I spoke with my manager about using zones, and his opinion is they’re crap – ok for one box, but not for the firewall usage I’m working on.

    You mean like the one I meant to use 25 or so years ago, basic2c? You let them do the mass conversion, then you fix it. A lot faster than rewriting
    *everything*.

    Unless you’re talking about a program that converts from, say, C, to lisp….

    mark ))))))))))))))))))))))))))))))))))

  • Then 2 years later you have to figure out why some obscure thing is happening, can’t read the converted code and just rewrite it all from scratch. [having been on that one for various programs converted via Fortran2C, Forth2C, Basic2C, and Prolog2C.] Yes it is good to do a simple job but if you are doing something complicated which it sounds like your firewall rules are doing.. then you need to just learn the new tool and use it OR keep using what you have with the iptables.services until it is EOL.

    —
    Stephen J Smoogen.

  • All right, so it’s a bad example, but it’s bad both directions.

    The problem of firewall rule conversion isn’t about protecting billions of dollars of investment in development by moving from a disfavored, underpowered programming language to a faster, better, and rising language. The economic incentive for a firewall rule conversion tool is much smaller.

    I don’t think it’s entirely uneconomic to solve this problem. I see two plausible options:

    1. Find everyone who has this problem, have them all chip in $1-5, and you’ll probably have enough to pay for the development of a tool at least as faithful as that BASIC to C translator you mentioned. We’ve got the crowdfunding platforms to make this possible.

    2. Find a single organization that’s got this problem badly enough that they’re willing to fund the development of this tool from their internal IT/development budget. You might stretch it to two organizations resulting in a pair of collaborating developers, but beyond that, you’ve got too many cooks in the kitchen for the size of the problem, so you go to #1.

    If you’re like me, both look like hard solutions, which is probably a better answer to your question than my language translator attempt.