[Firehol-support] run firehol before fail2ban
jonbae77 at gmail.com
Sun Jan 22 18:11:09 GMT 2017
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:
> 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:
> You could also try backporting from zesty, in the hopes (I have not
> checked) that the two have been made to work together:
> Get the firehol .dsc URL here:
> 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
> Hope that helps
More information about the Firehol-support