[Firehol-support] run firehol before fail2ban

[Jonathan Baecker]

Hi Phil,
thank you for your answer!

Yes I run fail2ban from package and firehol from git source. The 
standard firehol from package is version 2.0*, and with that I think I 
can not play with iptrap etc. Anyway I had try before native firehol 
from ubuntu package and there I had the same problem. It starts way to 
late, so it deletes fail2ban. Ok I have to say to, that I need it with a 
special config, so that it start only if a interface is up (from a VM).

For this situation I guess a backport solution or a init script will not 
really help. It would be great o have an option in firehol where I can 
run post commands after a firewall is establish, so I could say run me 
/service fail2ban restart/ after, but I think it is not integrated.

I need to try whats happen, if I remove the fail2ban init script and 
replace it with a systemd service. Maybe the update process will still work.



Am 22.01.2017 um 11:01 schrieb Phil Whineray:
> Hi
>
> On Sun, Jan 22, 2017 at 08:39:50AM +0100, Jonathan Baecker wrote:
>> Hello everybody,
>> sorry that I ask the question here, but I don't found info's for that in
>> google. How do you manage the starting behavior from firehol and fail2ban?
>> In my setup fail2ban starts before firehol, so when firehol start it delete
>> the settings from fail2ban. I run both on ubuntu 16.04, fail2ban runs here
>> not with an native systemd service.
> Looking at the packages, I think neither is a native systemd service
> and it looks like fail2ban is configured to start after firehol.
>
> So what exactly are you running? I will assume default fail2ban with
> firehol from source...
>
>> My thoughts  was:
>>
>> 1. I write a simple script what checks the firehol service, that it is
>>     active and start then fail2ban new
>> 2. I create a systemd service for fail2ban and put firehol.service to
>>     the after statement.
>>
>> The first solution is a bit dirty for me and with the second way I am not
>> sure how clean it will work, specially when it comes to system updates.
>>
>> What you think is the best solution?
> You could also try to use the ubuntu-provided init for the packaged firehol
> rather than the systemd service. Look here:
>       http://packages.ubuntu.com/xenial/firehol
>
> You could also try backporting from zesty, in the hopes (I have not
> checked) that the two have been made to work together:
>    https://wiki.debian.org/SimpleBackportCreation
>
> Get the firehol .dsc URL here:
>    http://packages.ubuntu.com/zesty/firehol
>
> It is still on 3.0.2 but it will probably track Debian to 3.1.x
> pretty soon.
>
> The backport process will require quite a few more packages but it
> should be pretty straightforward. Maybe you can just backport firehol
> or maybe you need to do fail2ban as well.
>
> Backport process is definitely the way that will play best with future
> upgrades.
>
> Hope that helps
> Phil