Harmonize SSH jail setup on Debian and Ubuntu

[ganto]

Depending on the distribution and the upstream jail configuration, the outcome of the role is slightly different. On Debian Jessie for example, a default jail ssh will be active even when fail2ban_jails is empty.

I therefore added a new task to adjust jail.conf on the different platforms in a way that it should be possible easily enable the ssh jail on all distributions via fail2ban_jails. This way it should result in the same setup no matter what distribution is chosen and the default SSH jail can easily be disabled by the user.

If you agree to enable the ssh jail by default, I'll still need to update the test suite to make sure the behaviour is as intended on Ubuntu, as I'm locally testing with Debian Jessie.

[drybjed]

The idea for making configuration the same on Debian and Ubuntu is good, I'm all for it.

The /etc/fail2ban/jail.conf configuration file is marked as a ConfFile in the fail2ban package. Therefore instead of modifying it directly I would rather see it diverted and templated instead. The template doesn't need to contain the various example jails, in fact I would leave most of the configuration directives intact and only handle differences between Debian and Ubuntu versions if there are any.

What do you think about going this route instead?

Edit: You can enable the SSH jail by default as well, it seems that it's one of the most used fail2ban jails anyway.

[ganto]

OK. That's definitely the cleaner approach. However this needs some new logic to figure out what's the correct logfile for sshd. Assumed this was already properly set in the distribution config.

[ganto]

Hmn, unfortunately it's much more complicated than only figuring out the logpath... 😞

I compared the jail.conf from 0.8.6-3 (precise, wheezy), 0.8.11-1 (trusty), 0.8.13-1 (jessie), 0.9.3-1 (xenial), 0.9.5-1 (yakkety) and 0.9.6-1 (zesty, stretch). It's 6 different versions with 5 different configuration files. Each new version adds some new options with a big refactoring after 0.9.0.

This means for each of the about 25 default configurations I would need to decide which version supports it and which don't. To me this looks like too much effort if the actual issue can be fixed with the simple task definition suggested in this PR.

What do you think?

[drybjed]

Getting the fail2ban version and using the version_compare filter to select what options are valid is the way to go in the long run.

How about this solution then:

• divert the /etc/fail2ban/jail.conf configuration file
• copy the original file back into place, from the .dpkg-divert file
• make modification as you see fit with lineinfile

This should be enough for now.

[ganto]

Getting the fail2ban version and using the version_compare filter to select what options are valid is the way to go in the long run.

I agree. But this also means that it would break all the jails which users defined based on the current example jails in jail.conf. Maybe such a change should be done together with changing the namespace to fail2ban__ so that users need to revise their configuration anyway.

[ganto]

ah... I'm still working on testing the successful setup of the default jail. There still seems to be something fishy (at least on precise)...

Is fail2ban not creating a socket by default? Error looks weird:

[...]
TEST: [In output | PASS]
found:
fail2ban-server

in output:
 8566 ?        Sl     0:00 fail2ban-server

TEST: [In file 'jail.local' | PASS]
found:
banaction

in output:
banaction      = iptables-xt_recent-echo-reject

DEBUG  Reading /etc/fail2ban/fail2ban
DEBUG  Reading files: ['/etc/fail2ban/fail2ban.conf', '/etc/fail2ban/fail2ban.local']
INFO   Using socket file /var/run/fail2ban/fail2ban.sock
ERROR  Unable to contact server. Is it running?

TEST: [Exit code 255 not 0 | FAIL]

[drybjed]

Ykes... OK, create a new PR then, if you won't have a fix by tommorow I'll revert the commit. No pressure. ;-)

[ganto]

Ok, I found the issue. It was simply a missing sudo 😃

[drybjed]

All right, so it looks like it works now.