Hi Christoph,
My responses are interspersed below.
On Wed, 11 Jan 2017, Christoph Theis wrote:
> Hello Igor!
>
> Am 10.01.2017 um 17:54 schrieb Igor:
>> 1. Suggestion:
>> I've been (mostly) successfully using fail2ban on a FreeBSD box for some
>> time, employing bsd-ipfw action to block the IPs.
>> When it does that, fail2ban adds the table as the first rule (unless there
>> are other tables):
>>
>> actionstart = ipfw show | fgrep -q 'table(<table>)' || ( ipfw show | awk
>> 'BEGIN { b = 1 } { if ($1 <= b) { b = $1 + 1 } else { e = b } } END { if
>> (e) exit e <br> else exit b }'; num=$?; ipfw -q add $num <blocktype>
>> <block> from table\(<table>\) to me <port>; echo $num > "<startstatefile>"
>> )
>>
>> The problem with that behavior is that it adds the table rule with the
>> number that correspond to the table number ($num), which in case of just
>> one table is "1".
>>
>> In some cases the firewall configuration may have rules that must be first
>> to prevent accidental lockdown of the server (especially if the server is
>> remote). Typical rule numbering (by default) in ipfw goes with a step of
>> 100. So, what would be very convenient is to add a configurable option for
>> bsd-ipfw that would be the lowest number for the table rule.
>>
>> Something like
>> ipfw_after_rule_number = 0
>> in jail.conf ,
>>
>> with a possibility to specify
>> ipfw_after_rule_number = 1000
>> in jail.local
>>
>> and then in bsd-ipfw:
>> rule_num = $num + $ipfw_after_rule_number
>
> The default works just fine with a default ruleset in FreeBSD: the first
> rules start at about 100 and the fail2ban rules are coming first.
> If someone modifies the rule set for a reason, in my opinion he would be
> better off if he adds the rules for fail2ban manually and disables the
> actionstart / actionstop commands.
>
I agree that the default configuration works fine with the default ruleset
in FreeBSD. [* see below] However, I am considering realistic use case
scenarios, such as the following one.
When I set up a new server, I first tweak the firewall configuration.
Then, I proceed to the installation of the most of packages (except maybe
for some crucial ones that could be installed prior to the firewall
configuration).
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.
[*] Actually, there is a very big potential conflict with the default
FreeBSD ipfw rule set. The rule set ( /etc/rc.firewall) [for any
firewall configuration option] starts with
setup_loopback() {
############
# Only in rare cases do you want to change these rules
#
${fwcmd} add 100 pass all from any to any via lo0
<snip>
fi
}
So, when fail2ban actionstart sets Rule 1 that is
unreach port ip from table(1) to me
and someone or something from the local host triggers one of the jail
rules, the loopback can be blocked, essentially disabling the rule 100
(in a rather sneaky way that might be easy to overlook while
troubleshooting the problem with some other server functionality that
relies on the loopback!).
> Though, it has some charme to have start rule number somewhere. I don't know
> if they have to be in jail.conf or if they could be in the bsd-ipfw.conf
> itself.
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.
But even if fail2ban would be happy with bsd-ipfw.local in the root
directory of the package, why should one have huge number of
site-configuration files? IMHO, it'd be better to configure only the
local counterparts of those config files that are already in that
directory, namely fail2ban.local and jail.local (and maybe
paths-overrides.local, which I personally missed due its obscurity [it has
not .conf counterpart], placing those into jail.local ).
>
>> 2. Existing problem:
>>
>> Also, what would make sense is to add a check if the specific rule already
>> exists in the active ipfw, to avoid accidental duplication of rule
>> numbers, as that would be
>> a problem when the rule is being deleted by fail2ban when it stops
>> (in actionstop). If more than one rule has the same number, fail2ban's
>> actionstop will delete all rules with that number.
>>
>> As far as I can tell, this check is currently missing: fail2ban only
>> checks if there is a table with the same number. The only
>> reason there is no collision is that no other script is using rule #1, but
>> can you rely on that?
>
> Can we have multiple rules with the same rule number? I'm not sure of that
> but then I never tried. I thought the awk script tries to fine the next free
> rule number. If we can have multiple rules under the same number then I
> agree: the script should continue until it finds a free rule number.
>
> This makes sense in any case, independent from your first point: there might
> be other software which tries to add rules automatically.
Exactly my point in regards to this (2nd) suggestion.
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.
Just in case: the awk inline script in the action quoted above is working
on the output of "ipfw show | fgrep -q 'table(<table>)' , which is only
trying to avoid a clash with an existing table.
>
> 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.
Best regards,
Igor
------------------------------------------------------------------------------
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
