The fail2ban.conf created by this cookbook doesn't have a pidfile entry. On Ubuntu 14.04 this generates warnings on restart/reload/etc:

 * Reloading authentication failure monitor fail2ban                                                    
WARNING 'pidfile' not defined in 'Definition'. Using default one: '/var/run/fail2ban/fail2ban.pid'
                                                                                                  [ OK ]

Warning emails are also generated by the weekly logrotate, so it's pretty annoying.

For ubuntu 10.04~14.04 (the versions I have handy..), it should have:

pidfile = /var/run/fail2ban/fail2ban.pid

in fail2ban.conf, but this path may be different on Redhat? I'd make a pull request but I don't have any non-ubuntu boxes to test it on sorry.

Hi ,

I'm able to recieve fail2ban start and stop notifications but i'm not able to get email notification when it is banning the ip address .

Please can you help me out on this ?

Thanks,
Naveen

A patch has already been submitted to correct the cookbook on Ubuntu 18.04, but a new release has not been submitted to the Supermarket. Would it be possible to tag and submit a new release so this cookbook will correctly work with Ubuntu 18.04+?

Issue Report Details

Cookbook version

5.0.2

Chef-client version

14.7.17

Platform Details

18.04.1

Scenario

Cookbook fails to correctly detect the system version of fail2ban.

Steps to Reproduce

Run cookbook on Ubuntu 18.04

Expected Result

Correct config syntax is used.

Actual Result

Old (< 0.9) config syntax is used.

Fail2ban cookbook ( and Chef::Provider::Service ) assumes Upstart for Ubuntu , but from 15.10 fail2ban uses systemd now .. the cookbook adds the wrong entries and seems to break fail2ban installation..

Fix, remove and purge fail2ban

I then added the following to the cookbook ( end of the default.rb )

service 'fail2ban' do
supports [:status => true, :restart => true]
action [:enable, :start]

if platform?('ubuntu') && node['platform_version'].to_f >= 15.10
provider Chef::Provider::Service::Systemd
end

if (platform?('ubuntu') && node['platform_version'].to_f < 12.04) ||
(platform?('debian') && node['platform_version'].to_f < 7)
# status command returns non-0 value only since fail2ban 0.8.6-3 (Debian)
status_command "/etc/init.d/fail2ban status | grep -q 'is running'"
end
end

Happy to propose a change, if someone can give a newbie a pointer or two

Expand the specs to cover each OS we support

Modern versions of fail2ban support .d folders, which should allow for failban LWRPs and the removal of the monolithic config. Lets see what OS releases include the versions supporting this and get a LWRP going.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update sous-chefs/.github action to v3.1.0
• Update Actions (major) (actions/stale, actionshub/chef-install)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Cookbook version

6.0.0

Chef-client version

14.12.9

Platform Details

CentOS 7

Scenario:

Create Fail2Ban Jail Configuration using fail2ban_jail resource (here for SSH service).

Steps to Reproduce:

fail2ban_jail 'ssh' do
  ports %w(ssh)
  filter 'sshd'
  logpath node['fail2ban']['auth_log']
  maxretry 6
end

Expected Result:

Created Fail2Ban Jail Configuration (here for SSH service).

Actual Result:

The fail2ban_jail resource does not provide a filter property. The following may work:

property :filter, String, required: true

Results in the following error:

NoMethodError
-------------
undefined method `filter' for Custom resource fail2ban_jail from cookbook fail2ban

Cookbook Trace:
---------------
 /tmp/kitchen/cache/cookbooks/fail2ban-wrapper/recipes/default.rb:11:in `block in from_file'
 /tmp/kitchen/cache/cookbooks/fail2ban-wrapper/recipes/default.rb:9:in `from_file'

Relevant File Content:
----------------------
/tmp/kitchen/cache/cookbooks/fail2ban-wrapper/recipes/default.rb:

 6:
 7:  include_recipe 'fail2ban'
 8:
 9:  fail2ban_jail 'ssh' do
10:    ports %w(ssh)
11>>   filter 'sshd'
12:    logpath node['fail2ban']['auth_log']
13:  end
14:

System Info:
------------
chef_version=14.12.9
platform=centos
platform_version=7.6.1810
ruby=ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux]
program_name=/opt/chef/bin/chef-client
executable=/opt/chef/bin/chef-client

Additonal Improvements:

Additionally the wrong attribute is given to internal template resource of fail2ban_jail resource. The problematic code is the following line:

# ...
property :source, String, default: 'jail.erb'
# ...
template "/etc/fail2ban/jail.d/50-#{new_resource.jail}.conf" do
  # ...
  source new_resource.filter # Prolematic code
  # ...
end
# ...

Should be:

# ...
property :source, String, default: 'jail.erb'
# ...
template "/etc/fail2ban/jail.d/50-#{new_resource.jail}.conf" do
  # ...
  source new_resource.source # Fix
  # ...
end
# ...

Without this fix the fail2ban_jail resource will not work properly. See: https://github.com/chef-cookbooks/fail2ban/blob/v6.0.0/resources/jail.rb#L33

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

The delivery check is failing.

🥞 Cookbook version

Version of the cookbook where you are encountering the issue.

👩‍🍳 Chef-Infra Version

Version of chef-client in your environment.

🎩 Platform details

Operating system distribution and release version. Cloud provider if running in the cloud.

Steps To Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

🚓 Expected behavior

All checks including integration tests should pass.

➕ Additional context

Add any other context about the problem here. e.g. related issues or existing pull requests.

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

Chef have released updated cookstyle rules, we should therefore run the auto fix against the cookbook

1. Ensure you are on the latest stable chef-workstation
2. Run cookstyle -a

Issue sprouted from sous-chefs/meta/issues/111. If not applicable then issue should be closed.

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

Update all CHANGELOGs to follow standard defined at https://keepachangelog.com/

Issue sprouted from sous-chefs/meta/issues/101. If not applicable then issue should be closed.

Cookbook version

5.0.0

Chef-client version

12.7.2

Platform Details

CentOS 7.2 via Kitchen

$ ohai --version
Ohai: 8.10.0

Scenario:

Installing fail2ban via the default recipe.

Steps to Reproduce:

I'm using the following .kitchen.yml file:

---
driver:
  name: vagrant

provisioner:
  name: chef_solo
  require_chef_omnibus: 12.7.2

platforms:
  - name: centos-7.2

suites:
  - name: default
    run_list:
      - recipe[fail2ban::default]
    attributes:

and execute kitchen converge.

Expected Result:

fail2ban is installed.

Actual Result:

chef-client throws an error:

Recipe: fail2ban::default
 * yum_package[fail2ban] action install
   - install version 0.9.7-1.el7 of package fail2ban
 * ohai[reload package list] action reload
   - re-run ohai and merge results into node attributes
 * ohai[reload package list] action nothing (skipped due to action :nothing)
 * template[/etc/fail2ban/fail2ban.conf] action create

   ================================================================================
   Error executing action `create` on resource 'template[/etc/fail2ban/fail2ban.conf]'
   ================================================================================

   NoMethodError
   -------------
   undefined method `[]' for nil:NilClass

   Cookbook Trace:
   ---------------
   /tmp/kitchen/cookbooks/fail2ban/recipes/default.rb:46:in `block (2 levels) in from_file'
   /tmp/kitchen/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/property.rb:11:in `get'
   /tmp/kitchen/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/mixin/params_validate.rb:11:in `get'
   /tmp/kitchen/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:78:in `run_action'
   /tmp/kitchen/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block (2 levels) in converge'
   /tmp/kitchen/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `each'
   /tmp/kitchen/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block in converge'
   /tmp/kitchen/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:105:in `converge'

   Resource Declaration:
   ---------------------
   # In /tmp/kitchen/cookbooks/fail2ban/recipes/default.rb

    41: template '/etc/fail2ban/fail2ban.conf' do
    42:   source 'fail2ban.conf.erb'
    43:   owner 'root'
    44:   group 'root'
    45:   mode '0644'
    46:   variables(lazy { { f2b_version: node['packages']['fail2ban']['version'].match(/^[0-9]+\.[0-9]+/)[0].to_f } })
    47:   notifies :restart, 'service[fail2ban]'
    48: end
    49:

   Compiled Resource:
   ------------------
   # Declared in /tmp/kitchen/cookbooks/fail2ban/recipes/default.rb:41:in `from_file'

   template("/etc/fail2ban/fail2ban.conf") do
     action [:create]
     retries 0
     retry_delay 2
     default_guard_interpreter :default
     source "fail2ban.conf.erb"
     variables #<Chef::DelayedEvaluator:0x00000003d85e98@/tmp/kitchen/cookbooks/fail2ban/recipes/default.rb:46>
     declared_type :template
     cookbook_name :fail2ban
     recipe_name "default"
     owner "root"
     group "root"
     mode "0644"
     atomic_update true
     path "/etc/fail2ban/fail2ban.conf"
   end


Running handlers:
[2018-02-15T08:52:36+00:00] ERROR: Running exception handlers
Running handlers complete
[2018-02-15T08:52:36+00:00] ERROR: Exception handlers complete
Chef Client failed. 7 resources updated in 21 seconds
[2018-02-15T08:52:36+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
[2018-02-15T08:52:36+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2018-02-15T08:52:36+00:00] ERROR: template[/etc/fail2ban/fail2ban.conf] (fail2ban::default line 41) had an error: NoMethodError: undefined method `[]' for nil:NilClass
[2018-02-15T08:52:37+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

I've added the kitchen config file to make it easier for you to reproduce the issue. We are also seeing the same error on our servers.

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

As part of our build process we should build each possible operating system separately

1. Ensure you have dokken setup and working:
2. dokken: aliased to KITCHEN_LOCAL_YAML=kitchen.dokken.yml kitchen
3. run dokken list, you should see a list of builds with dokken as the provider
4. download: https://github.com/sous-chefs/repo-management/blob/master/scripts/circleci_maker.rb and make this executable
5. run: dokken list -j | ./circleci_maker.rb > .circleci/config.yml

Issue sprouted from sous-chefs/meta/issues/112. If not applicable then issue should be closed.

Cookbook version

6.0.0

Chef-client version

15.0.300

Platform Details

  System Info:
  ------------
  chef_version=15.0.300
  platform=centos
  platform_version=6.10
  ruby=ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
  program_name=chef-client worker: ppid=28983;start=20:27:22;
  executable=/opt/chef/bin/chef-client

Scenario:

Used to do:

default_attributes fail2ban: {
  services: {
    'dovecot' => { enabled: 'true' },
    'postfix-sasl' => { enabled: 'true' } 
   }
}

which worked fine, since

[dovecot]
  enabled = true

which works perfectly, as other fields end up using defaults.

Trying to update to the new resource-based approach, but this doesn't work.

Steps to Reproduce:

fail2ban_jail 'dovecot' 
fail2ban_jail 'postfix-sasl' 

Expected Result:

Same result as before.

Actual Result:

    undefined method `filter' for Custom resource fail2ban_jail from cookbook fail2ban

because of unconditional use of new_resource.filter in fail2ban::default.

Cookbook version

6.0.0

Chef-client version

14.12.9

Platform Details

CentOS 7

Scenario:

I want to set the priority of the Fail2Ban Jail in conf.d directory.

Steps to Reproduce:

Call fail2ban_jail resource. This should be an improvement.

Expected Result:

Expect to create Fail2Ban Jail with priority in conf.d directory for Jail.

Actual Result:

Priority is hardcoded to 50.

# ...
action :create do
  template "/etc/fail2ban/jail.d/50-#{new_resource.jail}.conf" do # priority hardcoded to 50
    # ...
  end
end
# ...

Should be something like:

# ...
property :priority, [String, Integer], default: '50'
# ...
action :create do
  template "/etc/fail2ban/jail.d/#{new_resource.priority}-#{new_resource.jail}.conf" do # priority hardcoded to 50
    # ...
  end
end
# ...

See https://github.com/chef-cookbooks/fail2ban/blob/v6.0.0/resources/jail.rb#L31.

Hello

Using fail2ban on CentoS 7, tries for smtp relay are not blocked.
Adding this regex solve the problem on postfix.conf. Can you add it by default ?

^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+[]: 454 4.7.1 .*$

For info, log lines for these tries are :

Mar 1 18:26:24 server postfix/smtpd[14970]: NOQUEUE: reject: RCPT from unknown[50.60.146.24]: 454 4.7.1 [email protected]: Relay access denied; from=[email protected] to=[email protected] proto=SMTP helo=<relaytest.mydnstools.info>
Mar 1 18:26:25 server postfix/smtpd[14970]: NOQUEUE: reject: RCPT from unknown[50.60.146.24]: 454 4.7.1 returntest%[email protected]: Relay access denied; from=[email protected] to=returntest%[email protected] proto=SMTP helo=<relaytest.mydnstools.info>
Mar 1 18:26:25 server postfix/smtpd[14970]: NOQUEUE: reject: RCPT from unknown[50.60.146.24]: 454 4.7.1 [email protected]: Relay access denied; from=[email protected] to=[email protected] proto=SMTP helo=<relaytest.mydnstools.info>

Thanks

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

On the repo, ensure that Dangerfile matches https://github.com/sous-chefs/repo-management/blob/master/Dangerfile

Issue sprouted from sous-chefs/meta/issues/110. If not applicable then issue should be closed.

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

If the only thing in the .rubocop/yml is Dangerfile
Run the latest cookstyle
Remove .rubpopo.yml

Issue sprouted from sous-chefs/meta/issues/108. If not applicable then issue should be closed.

The attributes fail2ban.syslog_target & fail2ban.syslog_facility respectively set syslog-target & syslog-facility in the fail2ban.conf template.

I'm skeptical they do anything. fail2ban/server/server.py:378 indicates this is hardcoded to the daemon facility. I also have no idea what the syslog-target line could be about.

Unless there is an actual use for them, they should be removed.

The current base images for CentOS and RHEL on Softlayer are logging ssh errors to /var/log/messages rather than /var/log/secure. Because fail2ban is monitoring the other one, the cookbook configuration doesn't work by default:

http://serverfault.com/questions/646167/why-is-fail2ban-not-banning-this-attack/673112

I would suggest modifying the default for the cookbook to monitor both log files for CentOS and RHEL, either by having two paths in the logpath directive or defining two separate jails, one for /var/log/secure and one for /var/log/messages

In version 4.0 of this cookbook it's impossible to change the log level of fail2ban. In version 3.1.0 of this cookbook it was possible to change it but it was removed.

Is there a reason why?

At least for Ubuntu 16.04 LTS which has version 0.9.3 of fail2ban you can set the log level using one of these values.

Ubuntu 14.04 LTS seems to use 0.8.x where the values are different.

Does that mean that Ubuntu 14.04 is not supported anymore after version 4.0 of this cookbook?

Cookbook version

3.1.0

Chef-client version

[Version of chef-client in your environment]

Platform Details

Ubuntu 16.04

Scenario:

0.9.3-1

Steps to Reproduce:

Install cookbook as is - fails to start fail2ban

Expected Result:

cookbook works on current version of ubuntu

Actual Result:

cookbook doesn't work

Cookbook version

4.0.1

Chef-client version

13.6.4

Platform Details

Fedora 27

Scenario:

Start and enable fail2ban

Steps to Reproduce:

Run on Fedora 27

Expected Result:

Run should enable and start fail2ban

Actual Result:

Doesn't start or enable due to platform_family not matching in recipes/default.rb

service 'fail2ban' do
  supports [status: true, restart: true]
  action [:enable, :start] if platform_family?('rhel')
  action [:enable] if platform_family?('debian')
end

Adding fedora as a platform_family in my wrapper cookbook fixed it.

ohai | grep platform_family
[2018-01-07T21:31:23+00:00] INFO: The plugin path /etc/chef/ohai/plugins does not exist. Skipping...
"platform_family": "fedora",

A meta-issue.. If I open a ticket here, it asks me to see the guidelines for contributing. They say to open a ticket in Jira, but Jira tells me to open a ticket here.

I'm pretty sure here is the right location?

Cookbook version

"fail2ban","version":"5.0.1"

Chef-client version

chef-12.20.3-1.el7.x86_64
chef-server-core-12.15.8-1.el7.x86_64

Platform Details

Red Hat Enterprise Linux Server release 7.4 (Maipo)
Linux 3.10.0-693.17.1.el7.x86_64 x86_64 GNU/Linux

Scenario:

Fail2ban cannot start with command: "systemctl start fail2ban.service"

Steps to Reproduce:

1. Try to start Fail2ban with command: "systemctl start fail2ban.service"
2. Check for directory existence (dir /var/run/fail2ban was not created automatically during the installation)

Error captured in /var/log/messages
chef fail2ban-client: ERROR There is no directory /var/run/fail2ban to contain the socket file /var/run/fail2ban/fail2ban.sock.
chef systemd: fail2ban.service: control process exited, code=exited status=255
chef systemd: Failed to start Fail2Ban Service.
chef systemd: Unit fail2ban.service entered failed state.
3. Manually create missing dir (mkdir -p /var/run/fail2ban)
4. Fail2ban was properly started with command: systemctl start fail2ban.service

Expected Result:

There should be possible to start Fail2ban without changing the paths (when Fail2ban cookbook is included with Berksfile).

Actual Result:

Actually, Fail2ban was included with Berksfile, variables are overwritten with environment variables.
If we change the path to fail2ban.sock file from /var/run/fail2ban/fail2ban.sock into /var/run/fail2ban.sock - other installation parts will still use old path. Temporary fix would be to manually created missing /var/run/fail2ban dir.

Including this recipe and the community/chef iptables recipe doesn't always end up putting fail2ban rules in the current iptables chains.