what's the current hotness in managing multiple iptables installations

Jump to latest Follow Reply
W

wobblytickle

Ars Praetorian
596
  • #1
    how do you like to do it ;)

    I've been asked by a friend to help with his small fleet; he's got 15-20 nodes that he wants to get iptables rules set up. They're all bare metal and with a bunch of hosting providerss so he doesn't have much in the way of orchestration. He does have scripts tho' and they're all members of a simple Puppet setup.

    My goto for this sort of thing used to be fwbuilder* but because it's unsupported I'm also looking elsewhere... and not liking what I see. He has Puppet as I said so looked at things like puppetlabs-firewall but that all just feels both clunky and wrong (depending on exported resources for a firewall rule.... no). Googling turns up folks solving this with Ansible but given he has no Ansible that seems to me to be worse than the Puppet solution:- swapping a clunky DSL for yaml and then all the boilerplate for Ansible to boot. I see there's a SaaS offering called fwcloud which is great but that's presumably $$. I found dog which would be promising but architecturally seems oddly complex. I'm just astonished that noone has a solution that's fully open, or my Googling is crap. Can Foreman do such a thing? what am I missing?

    *fwbuilder was great for this because it had failsafes for script roll-out but way way more importantly had a really slick object model and supported dependencies and would (re)generate rules on the fly, check them for issues and deploy them to the target(s) affected. Sadly it became abandomware I think in 2013, forked/copied to github in 2017 and whilst the github folks are keeping the buidls running and it's still in Ubuntu that was 6 years and things have moved on... I'd actually given up on it because on my 22.04 box it would segfault but on this 23.04 it doesn't. Either way, doesn't bode well; and that there isn't a successor is worse!
     
    K

    koala

    Ars Tribunus Angusticlavius
    7,579
  • #2
    I knew a person that actually used Puppet via the CLI to manage iptables because he found the module for firewalls in Puppet to be more intuitive than the iptables commands themselves.

    Looking at the docs, I don't see how it relies on exported resources? I mean, you can probably use exported resources to do fancy stuff like setting port forwarding in host A to access a service in host B, but that's reasonable. But it sounds like you could define a host's firewall rules without using exported resources? (I actually wrote some code to simulate exported resources in masterless Puppet. It's very clunky, but it works. I use it for Nagios.)

    Puppet is falling out of style, but you really can do a lot of nifty things to keep the configuration declarative. If your friend uses Puppet, it might be worth persevering. I started using Puppet about 10 years ago, but only recently some of the fancy things you can do really clicked for me (actually, I think it was after using Kubernetes more that I appreciated some stuff in Puppet).

    It's really cool when your Apache module controls the firewall automatically, for example.

    If you have complex enough rules, I guess you could easily encode them in YAML and have a program apply those (or create the config files for some of the iptables scripts that some distributions use). The fact that not a lot of people work on this kind of things is likely a mixture of a) big environments using firewall appliances b) writing generic-enough software for this is hard, because different people have different needs oc) it's not worthwhile and people just learn iptables d) it's so easy writing your small DSL that it's not worth talking about it.
     
    • Like
    Reactions: wobblytickle
    W

    wobblytickle

    Ars Praetorian
    596
  • #3
    koala said:
    Looking at the docs, I don't see how it relies on exported resources? I mean, you can probably use exported resources to do fancy stuff like setting port forwarding in host A to access a service in host B, but that's reasonable.
    Click to expand...
    it doesn't, but that's precisely the sort of thing he needs: allow access to port X on host A from host B. I find that objectionable because eventually consistent works in some cases (say, new node C coming online and need ing acces to A:X) but not most (host A moved addresses everything needs to know now). mco would help with that but still to me it feels like it's sat in the wrong place.

    I appreciate the post because it has me thinking: I think where I am now is that I feel Puppet is the wrong place for this because it can report on it (i.e. facts, extending to exported resources) but isn't in control.

    So the question remains, is there any iptables orchestration that is feature complete/competitive with/respect to fwbuilder...
     
    K

    koala

    Ars Tribunus Angusticlavius
    7,579
  • #5
    Oh, if you need that, then I think Puppet is as good as it gets.

    I run masterless Puppet using Ansible simulating exported resources, so I can do changes like that quasi-transactionally. That is, I make changes to my infrastructure, run Ansible and that applies the new version of manifests in parallel in my nodes.

    I suspect there aren't many alternatives out there. Terraform and friends likely can do similar thing with cloud SDNs, but I suspect they don't do much iptables.

    Now I understand that "dog" mention. You mentioned Foreman- I'm not familiar with it, but likely you can use it to orchestrate such changes. And there's of course Bolt, although I haven't played with that.

    As I mentioned, you're likely experiencing the effects of appliance firewalls being common place in the large, hard to manage environments. Where I hear that Ansible, very surprisingly to me, is a thing.
     
    T

    teubbist

    Ars Scholae Palatinae
    823
  • #6
    koala said:
    If you have complex enough rules, I guess you could easily encode them in YAML and have a program apply those (or create the config files for some of the iptables scripts that some distributions use). The fact that not a lot of people work on this kind of things is likely a mixture of a) big environments using firewall appliances b) writing generic-enough software for this is hard, because different people have different needs oc) it's not worthwhile and people just learn iptables d) it's so easy writing your small DSL that it's not worth talking about it.
    Click to expand...
    Or as an extension to a) or as e) firewalling is provided by your infrastructure stack(NSX, Nova/Neutron SG's, the equivalents in cloud providers, etc). Which comes with an API that drives how you interact with and deploy rules

    "build rules in one place and distribute" has also likely fallen out of fashion because stuff like docker/podman will happily break whatever you've deployed, so a certain amount of local decision making needs to exist in the rule generator.

    For iptables I've personally gone with a variant of d), where I keep a service map in my orchestrator(Salt Pillar) and then use templating to generate the rules. The templating encodes a fair amount of business logic so falls into the "not easily exported/shared" banner.

    If I was to do it again I'd probably look at firewalld more seriously, pushing zone definitions and rules from configuration management.
     
    W

    wobblytickle

    Ars Praetorian
    596
  • #7
    teubbist said:
    "build rules in one place and distribute" has also likely fallen out of fashion because stuff like docker/podman will happily break whatever you've deployed, so a certain amount of local decision making needs to exist in the rule generator.
    Click to expand...
    or ignoring. This was already on my radar but I can't walk yet let alone run...
    teubbist said:
    For iptables I've personally gone with a variant of d), where I keep a service map in my orchestrator(Salt Pillar) and then use templating to generate the rules. The templating encodes a fair amount of business logic so falls into the "not easily exported/shared" banner.

    If I was to do it again I'd probably look at firewalld more seriously, pushing zone definitions and rules from configuration management.
    Click to expand...
    firewalld is RedHatish right?

    Try as I might I can't get fwbuilder to play ball, it did initially on this lappy at least enough to recompile rulesets but something shonky going on with object creation/refresh when objects > 1. Much more annoying the same case on Ubuntu's 23.04, 22.04, 20.04, and Debian Buster, and Fedora 38 (you can see my resistance to having to reinvent the wheel :)

    I dunno, it feels like such a regression that a tool like this is dead, or, rather, the gap its death opens is painful as technology solutions 'move on to better things'
     
    T

    teubbist

    Ars Scholae Palatinae
    823
  • #8
    wobblytickle said:
    firewalld is RedHatish right?
    Click to expand...
    Yes, but last I checked Ubuntu and Debian have mainline packages for it.

    Between it supporting both iptables and nftables, reasonable pickup by various applications for integration(i.e. Docker creates a docker zone and mostly plays by the rules) and it being RH'ish backed does mean it's less likely to suffer fwbuilder's fate.

    edit: the nftables thing is I guess another reason to not burn cycles on fwbuilder. While it's probably a decade+ out before Linux completely removes iptables, nftables is where all the cool kids hangout now.
     
    Last edited:
    • Like
    Reactions: wobblytickle
    W

    wobblytickle

    Ars Praetorian
    596
  • #9
    teubbist said:
    edit: the nftables thing is I guess another reason to not burn cycles on fwbuilder. While it's probably a decade+ out before Linux completely removes iptables, nftables is where all the cool kids hangout now.
    Click to expand...
    yep definitely. fwiw I got a stable fwbuilder building from source but prescient as you often are @teubbist the shell glue fwbuilder lean on doesn't get along with iptables-nft (or its sufficiently subtly different to iptables-legacy) but me nor my friend aren't in a position to argue given this needs to be done next week; such is life!
     
    You must log in or register to reply here.
    Jump to latest Follow Reply
    Jump to latest Follow Reply