firewall.service breaks fail2ban in ansible-role-security

[kurtabersold]

I am using ansible-role-security with ansible-role-firewall. There seems to be a problem with the firewall.service script which clobbers fail2ban rules in the firewall after a systemctl restart firewall.service

My main.yml is bringing in the roles in this order:

  roles:
    - { role: geerlingguy.security }
    - { role: geerlingguy.firewall }

[geerlingguy]

Hmm... I'm not 100% sure I want to go with the approach in #32, but that might be somewhat necessary. I've sometimes run into the same chicken-and-egg issue with Docker (when you bring up Docker containers, if Docker was started prior to this role making some modifications, that can cause some issues).

[mprasil]

I tried to have a go at the problem in #37. In theory you just need to set these variables for docker host to avoid conflict with Docker-added rules:

firewall_flush_filter_chains:
  - INPUT
  - OUTPUT
firewall_flush_nat_chains:
  - INPUT
  - OUTPUT
firewall_delete_chains: []

Similar configuration should work for fail2ban.

Obviously this will not work optimally if there are also defined forwarded ports, but hopefully this should be very edge case scenario that adds some slight performance penalty - multiple rules, that will only match on the first one.

And even in that case it only won't be optimal when applying the rules multiple times, so once at boot should be good. We can perhaps check if this conflict is present and throw some warning if that's the case, I'm just not sure it's worth the effort.

[JMLX42]

In theory you just need to set these variables for docker host to avoid conflict with Docker-added rules:

I used those rules and after a fresh provisioning, my containers won't run before I restart docker :

$ docker ps
CONTAINER ID        IMAGE                          COMMAND             CREATED             STATUS                                  PORTS               NAMES
e2765cdc8ae6        gitlab/gitlab-ce:10.0.1-ce.0   "/assets/wrapper"   47 seconds ago      Restarting (1) Less than a second ago                       gitlab

Restarting the docker service fixes the issue.

[romaindequidt]

I'm using geerlingguy.firewall and tersmitten.fail2ban roles.
To solve that issue, I use listen feature for handlers in Ansible (>= 2.2)
I create ansible-role-fail2ban-handler-for-firewall role in my playbook with 1-handler file roles/ansible-role-fail2ban-handler-for-firewall/handlers/main.yml :

# handlers/main.yml
- name: handler restart fail2ban service after firewall restarted
  service:
    name: fail2ban
    state: restarted
  listen: restart firewall

and update my playbook:

- hosts: all
  roles:
    - role: geerlingguy.firewall
    - role: tersmitten.fail2ban
    - role: ansible-role-fail2ban-handler-for-firewall # global handler, keep at the end of playbook

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[geerlingguy]

Not stale; I'm going to add a simple approach (like #37 but just one variable to determine whether to flush or not, for now) to make it so this role can work more easily with Docker and other tools that modify iptables on their own... I don't want to necessarily add more complexity in the behavior like #37 does where strings and empty sets mean different things.

[stale]

This issue is no longer marked for closure.

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[stale]

This issue is no longer marked for closure.

[geerlingguy]

Also @romaindequidt - TIL about the listen option for handlers. That's nice, being able to tag onto other handlers like that! I could rewrite a couple of my older roles to use that feature so I don't have to have cross-role deps.