ufw or iptables module

I'm conceptually interested, though I think there is a reason iptables
is *typically* best managed by a template and then issuing a service
load command. (Namely, expressing rules some other way is a little
difficult, because there is so much you can do). Curious what you
had in mind?

Note Fedora18 is apparently going to Firewalld -- haven't tried it yet.

I like the idea of being able to easily punch holes in firewalls.

I think Seth Vidal was using lokkit in his playbooks for this purpose.

--Michael

I use shorewall to manage iptables, and rely on its support for a rules.d directory.

In /etc/shorewall/rules:

SHELL cat /etc/shorewall/rules.d/*.rules

Then, each service that needs a port open installs its own rule file, e.g.:
/etc/shorewall/rules.d/ssh.rules

Shorewall’s formats are simple enough to manage with templates.

I haven’t though too much into how to do this task yet. It’s an outstanding action item for what I need to maintain with ansible. In the past when I used chef, I did indeed use a template to generate a shell script.

Conceptually, I like that there’s an authorized_keys module. I don’t want to be bothered with generating the actual file, I just want to describe what keys I do and do not want on this host. I’d like to create a ufw module that provides a similarly clean abstraction.

My organization is currently using ufw to maintain the firewall rules, so if I’m going to be developing something (which it sounds like I will be doing), then I will be targeting this. However, this is my first exposure to ufw so I’m not sure of the best way to manage this.

It appears that ufw uses iptables rules files, so I suppose I could just template this. The assemble module looks interesting as well. However, I think I could also use ufw directly, taking advantage of --dry-run to determine whether or not this task will be “ok” or “changed”. Do any other modules spawn child processes, or are most things done in process with pure Python? I’m very open to suggestions about this, if people have any opinions.

To be honest, I think I’m just excited about an opportunity to learn more about ufw and ansible. I’m naturally curious about my systems and tools.

It appears that ufw uses iptables rules files, so I suppose I could just
template this. The assemble module looks interesting as well. However, I
think I could also use ufw directly, taking advantage of --dry-run to
determine whether or not this task will be "ok" or "changed". Do any other
modules spawn child processes, or are most things done in process with pure
Python? I'm very open to suggestions about this, if people have any
opinions.

It's totally ok for them to call other shell commands, and many
modules do. Main thing
is only to call them to change things when a change is needed (basic
idempotency stuff).

To be honest, I think I'm just excited about an opportunity to learn more
about ufw and ansible. I'm naturally curious about my systems and tools.

Cool!

I’d love to see some declarative handling for iptables in ansible - I’d like to be able to declare a bunch of rules that need to exist and have the module worry about whether they currently exist or not. Having said that, I’d be intrigued as to how you delineate between asserting the existence of additional rules that aren’t already in iptables and being able to assert the entire state of the iptables (i.e. delete the entire table and reload each rule).

I was using lokkit out of laziness and out of a desire to send a playbook to someone that would do everything w/o having to include a template file w/it.

-sv

This is awesome… Thank you!

It seems there is an iptables frontend called “ferm” that does the trick quite nicely based on a single config file and templates. I will give it a shot and document the results afterwards, but using this might solve the issue without custom modules.

I actually found Ferm via the Sovereign set of playbooks a while back. I just couldn’t quite make the pieces fit together well enough to write a role for it, and the one from Sovereign didn’t work for me when looked at it…

Fortunately, I found that I can template /lib/ufw/user.rules and make ufw work for me a few days ago.

Templating rules that look like:

tuple ### allow any 22 0.0.0.0/0 any 0.0.0.0/0 in

-A ufw-user-input -p tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp --dport 22 -j ACCEPT

tuple ### allow any 443 0.0.0.0/0 any 0.0.0.0/0 in

-A ufw-user-input -p tcp --dport 443 -j ACCEPT
-A ufw-user-input -p udp --dport 443 -j ACCEPT

Is a lot easier than FireHOL, ferm, or Shorwall’s methods.

'Course, I think my role is pretty limited in what it can do, but still, at least it makes sense to me. :slight_smile:

My ufw role is still very rough and I’ve only tested it on a vagrant vm, so I don’t really have anything to share. But at least you all know it’s possible. :slight_smile:

I have been using a home-grown ufw module for a while. Just today I
decided to submit a pull request to get it pulled in to ansible:

https://github.com/ansible/ansible/pull/5048

Please test, comment, add feature requests, etc.

- James

Now there is an ufw module.

http://docs.ansible.com/ufw_module.html