Re: run firehol before fail2ban
Jonathan Baecker <[email protected]> Sun, 22 Jan 2017 19:11:09 +0100
| Newsgroups | gmane.comp.security.firewalls.firehol.user |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ Firehol-support mailing list [email protected] http://lists.firehol.org/mailman/listinfo/firehol-support