Hello Igor!
To clarify: I'm maintaining the FreeBSD port of fail2ban but I'm not
involved in the development upstream, at least not in a way I could
decide what they'll include in the next version or not. But because I'm
using fail2ban on FreeBSD I took the liberty to write my point-of-view.
Am 12.01.2017 um 03:41 schrieb Igor:
> So, when I install fail2ban I am working with already checked and
> verified ruleset configuration of ipfw. (And in some cases, people might
> install fail2ban many months later, - just because they found this
> package and/or realized the need for it.)
> So, during the installation, I'd check and tweak the configuration of
> the package. And that's where additional configurability of fail2ban (as
> proposed) would be handy.
> That's the rational. And if it can be done as _configuration_ (in
> jail.local and fail2ban.local) as opposed to any over-writing and
> disabling procedures, as you implied, that would make it more
> transparent (especially for less experienced admins) and easier.
I'm not opposed to have it configurable. Just I can't say if this,
tweaking and checking firewall rules and than leave it to some package
to change them, is a real world scenario or not. I'm not an admin
(except for my personal servers), so if you say so I'll believe you.
> As far as I understand the logic of configuration used by fail2ban, all
> site-specific options should go into
> ${fail2ban_package_root}/jail.local, where all *.local config files are
> expected (including fail2ban.local and path-overrides.local).
> Since bsd-ipfw.conf is in action.d/ , I'd expect it would be against
> that logic to do site-specific configuration in it.
I thought .local can be anywhere, where the .conf master is.
So to change action.d/bsd-ipfw.conf you add a action.d/bsd-ipfw.local.
At least it used to be in earlier version, I never tried it in the 0.9
branch.
I suggested to define and change the variables there so the main
configuration files are not cluttered. But that is a matter of taste if
you want to have all possible variables in one place (easier to edit) or
define them where they are used.
So we agree the start number from which bsd-ipfw starts looking to place
the rule into, shall be configurable. May upstream decide where to put
the variable.
> And yes, ipfw will silently accept multiple rules with the same number.
> And "ipfw delete $num" will delete all of them. I've tested that.
Then we need the check in any case.
>> PS: Because you are using fail2ban under FreeBSD:
>> I think that the default path for the apache log files are still wrong.
>> Can you confirm that? If yes, we should have upstream patch it.
>>
>
> It's been long time since I've used default path for the apache log
> files. So, I just looked at the httpd.conf.sample that was installed on
> a relatively recent server via pkg (package management system under
> FreeBSD), and I see the following path there (which I assume are FreeBSD
> default ones):
>
> ErrorLog "/var/log/httpd-error.log"
> CustomLog "/var/log/httpd-access.log" common
>
> I believe those are the default paths.
Then we are 2 :)
Best regards
Christoph
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
