[prev in list] [next in list] [prev in thread] [next in thread]
List: fail2ban-users
Subject: Re: [Fail2ban-users] [Possible SPAM] Re: fail2ban and path to iptables
From: Rhys McWilliams <rhys () castlehillcc ! co ! za>
Date: 2015-11-17 10:40:36
Message-ID: 564B0424.7080005 () castlehillcc ! co ! za
[Download RAW message or body]
Hi,
The main reason I changed to using ipset was because of my my rather
large block list that you have to wait for f2b to unban each entry when
issued with a stop.
This in itself is not too much an issue but I restart my firewall
whenever my ADSL connection gets a new IP so that certain firewall rules
know bout the new IP and waiting for f2b to unban 1500+ entries was
taking way too long.
I had looked at various ways of trying to get f2b to just flush/dump the
chain entries but it didn't seem to work as expected and ipset was the
best solution.
I went from waiting about 3 minutes for a f2b stop and iptables restart
down to under half a second as I only had to restart my iptables setup...
I do agree that the management of the ipset structure is a little more
complicated but I'll eventually get around to writing a simple unban
script that does the f2b side and the ipset side too, just haven't yet
had the desperate need to unban in a hurry...
Regards
------------------------
Rhys McWilliams
Cell: +27 82 335-5014
Fax: 086 618-2798
http://www.castlehillcc.co.za
rhys@castlehillcc.co.za
On 2015/11/17 10:56, Nick Howitt wrote:
> There are a couple of issues with ipset.
>
> Firstly, although its blocking and loading is much faster, it is not
> nearly so easy to spot blocks at a glance and manage them if
> necessary. It is also harder to unban as, with your method you don't
> have an unban rule, relying on ipset block to expire. Manually, you
> need to both delete the ipset block and issue an unban command to
> remove it from the f2b database. This is really a management issue.
>
> The other issue is again our friend, iptables. On my version (1.4.7?
> on el6) iptables cannot remove an ipset rule directly using the normal
> -D switch. This is fixed in later versions of iptables. Fortunately
> these rules are relatively easy to find if there is one rule per set (
> so not a udp and tcp rule although this can be got round with a loop)
> so they can be deleted by listing the table with line numbers,
> grep'ing the jump target then picking out the line number of the rule
> and deleting that. Messy. Without this, stopping f2b would leave the
> iptables rule in place.
>
> Personally I really like the ipset approach apart from its visibility.
>
> Regards,
>
> Nick
>
> On 2015-11-17 08:16, Rhys McWilliams wrote:
>> Hi,
>> I stand to be corrected but as far as I know f2b does not have a
>> "recovery mechanism" that will attempt to re-create the chains if
>> they've been removed by some other means.
>> Those log entries don't seem to show f2b trying to re-create the
>> chains...
>> The "iptables -D" is an attempt at removing a chain rule.
>> The "iptables -F" is the chain flush command and
>> the "iptables -X" is the deletion of chain command.
>> If f2b was trying to create the chain there should be "iptables -N"
>> command to create the "new" chain.
>>
>> It is also most definitely not a path issue or else you would be getting
>> different error messages and your one log line
>> "iptables v1.4.21: Couldn't load target `f2b-sshd':No such file or
>> directory\n\nTry `iptables -h' or 'iptables --help' for more
>> information.\niptables: No chain/target/" could only possibly return
>> such an error if it had actually executed iptables...
>>
>> If I am incorrect about the f2b recovery mechanism then I do agree that
>> it would be nice for it to work but there is nothing wrong with creating
>> scripts to "work around" issues until said issues has been resolved and
>> the script therefore no longer required.
>>
>> There is another solution to this and that is to use iptables with the
>> set and mark parameter and use f2b to populate an ipset list which does
>> not get flushed when iptables restarts and f2b can happily access it as
>> needed.
>> I've changed to this method as one of my f2b rules has built an ipset
>> list that currently contains 1718 entries of IPs to block and I can
>> restart my iptables as often as I like without effecting that list or
>> f2b...
>>
>> Regards
>> ------------------------
>> Rhys McWilliams
>> Cell: +27 82 335-5014
>> Fax: 086 618-2798
>> http://www.castlehillcc.co.za
>> rhys@castlehillcc.co.za
>>
>> On 2015/11/17 10:00, Nick Howitt wrote:
>>> With later versions of iptables (not mine!) which support the -C
>>> (check)
>>> switch, you can avoid the issue by changing the actionunban (and
>>> actionstop?) rules to check if the rule exists first before deleting
>>> it.
>>> I've done an ugly bash/grep hack to my rules as I use a restricted set.
>>> The overall result is a tidy log but I'm sure it takes a bit longer to
>>> execute. It is me just being a purist.
>>>
>>> Nick
>>>
>>> On 2015-11-17 07:39, Y. wrote:
>>>> In my opinion, your issue is not a PATH issue, but simply that the
>>>> fail2ban chain does not exist anymore after the firewall has been
>>>> reset. Restarting fail2ban does recreate the chain, which is why it
>>>> works thereafter. I see two solutions:
>>>> - either you add the creation of the fail2ban chain to your firewall
>>>> rules: this would avoid the errors, but it would not restore the bans;
>>>> - or you create a script as already suggested: stop f2b, tweak fw,
>>>> start f2b.
>>>>
>>>> On Tue, 17 Nov 2015, Stein Rune Risa wrote:
>>>>> Hi!
>>>>> Yes, I understand this is happening because of the flushing of rules,
>>>>> but it seems that fail2ban has a built-in recovery mechanism to
>>>>> handle
>>>>> this situation.
>>>>>
>>>>> The recovery mechanism is to readd the iptables rules (see log
>>>>> from my
>>>>> original mail).
>>>>>
>>>>> The issue is that the recovery mechanism is not working - because
>>>>> PATH
>>>>> is not set correctly for fail2ban - which was my original question.
>>>>>
>>>>> I don't want to create scripts to compensate for this, when I can fix
>>>>> the original issue instead, which is to get the recovery mechanism to
>>>>> work properly.
>>>>>
>>>>> So the question still remains: how can I set the PATH for the
>>>>> fail2ban
>>>>> process?
>>>>>
>>>>> Best regards
>>>>> Stein Rune Risa
>>>>>
>>>>> On Tue, Nov 17, 2015 at 7:33 AM, Rhys McWilliams
>>>>> <rhys@castlehillcc.co.za> wrote:
>>>>> Hi,
>>>>> Those errors you are seeing are due the iptables restart,
>>>>> which
>>>>> would have flushed and removed all the chains, including the ones
>>>>> f2b creates.
>>>>> This is normal behaviour when iptables is restarted (which is
>>>>> what is happening with iptables-restore).
>>>>> The log entries below are from f2b trying to work on one of
>>>>> the
>>>>> chains it knew it had created when it started, but that chain no
>>>>> longer exists due to the iptables restart.
>>>>> Restarting f2b would re-create the relevant f2b chains and
>>>>> therefore function as expected again.
>>>>>
>>>>> What I had done to overcome this was to create a script to
>>>>> restart the firewall, which basically first does a fail2ban stop then
>>>>> restarts iptables and then starts fail2ban again so all was as
>>>>> it should be...
>>>>>
>>>>> ##### fwrestart.sh #####
>>>>> #!/bin/bash
>>>>>
>>>>> /etc/init.d/fail2ban stop
>>>>> /etc/init.d/iptables restart
>>>>> /etc/init.d/fail2ban start
>>>>>
>>>>> Regards
>>>>> ------------------------
>>>>> Rhys McWilliams
>>>>> Cell: +27 82 335-5014
>>>>> Fax: 086 618-2798
>>>>> http://www.castlehillcc.co.za
>>>>> rhys@castlehillcc.co.za
>>>>> On 2015/11/16 21:03, Stein Rune Risa wrote:
>>>>> Hi!
>>>>> I am using fail2ban and very happy with that. But I have one use case
>>>>> where behavior is not optimal.
>>>>>
>>>>> I store my iptables rules in a file an occasionally run
>>>>> iptables-restore if I have modified the rule set.
>>>>>
>>>>> After I have done this, I see the following errors in fail2ban-log:
>>>>>
>>>>> 2015-11-16 07:58:26,043 fail2ban.action [3074]: ERROR
>>>>> iptables -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
>>>>> iptables -F f2b-sshd
>>>>> iptables -X f2b-sshd -- stdout: b''
>>>>> 2015-11-16 07:58:26,044 fail2ban.action [3074]: ERROR
>>>>> iptables -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
>>>>> iptables -F f2b-sshd
>>>>> iptables -X f2b-sshd -- stderr: b"iptables v1.4.21: Couldn't load
>>>>> target `f2b-sshd':No such file or directory\n\nTry `iptables -h'
>>>>> or 'iptables --help' for more information.\niptables: No
>>>>> chain/target/m$
>>>>> 2015-11-16 07:58:26,044 fail2ban.action [3074]: ERROR
>>>>> iptables -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
>>>>> iptables -F f2b-sshd
>>>>> iptables -X f2b-sshd -- returned 1
>>>>> 2015-11-16 07:58:26,044 fail2ban.actions [3074]: ERROR
>>>>> Failed
>>>>> to execute ban jail 'sshd' action 'iptables-multiport' info
>>>>> 'CallingMap({'ipmatches': <function
>>>>> Actions.__checkBan.<locals>.<lambda$
>>>>>
>>>>> I think this is because the iptables entries for fail2ban have been
>>>>> flushed, and it is trying to restore them - but cannot find
>>>>> the iptables executable.
>>>>>
>>>>> I have to do a sudo service fail2bank stop and then start to resolve
>>>>> this issue. That restores iptables entries for fail2ban and
>>>>> fixes the issue.
>>>>>
>>>>> I've examined the /etc/init.d/fail2ban script and find:
>>>>>
>>>>> PATH=/usr/sbin:/usr/bin:/sbin:/bin
>>>>>
>>>>> iptables is in /sbin, but it seems to use this PATH variable just
>>>>> when
>>>>> it starts up - because it manages to set iptables rules OK
>>>>> on start - but not when running.
>>>>>
>>>>> I see that fail2ban process runs as root (from htop):
>>>>>
>>>>> 3580 root 20 0 282M 18196 6516 S 0.0 0.9 0:06.90 ├─
>>>>> /usr/bin/python3 /usr/bin/fail2ban-server -s
>>>>> /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x
>>>>> -b
>>>>>
>>>>> I would rather not add fail2ban entries to my iptables rule file -
>>>>> but
>>>>> I hope there is somehow to make fail2ban being able to
>>>>> execute iptables runtime. A path variable somewhere that I can set to
>>>>> include /sbin.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Best regards,
>>>>> Stein Rune Risa
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> Presto, an open source distributed SQL query engine for big data,
>>>>> initially
>>>>> developed by Facebook, enables you to easily query your data on
>>>>> Hadoop
>>>>> in a more interactive manner. Teradata is also now providing full
>>>>> enterprise
>>>>> support for Presto. Download a free open source copy now.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Fail2ban-users mailing list
>>>>> Fail2ban-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Fail2ban-users mailing list
>>>> Fail2ban-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Fail2ban-users mailing list
>>> Fail2ban-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Fail2ban-users mailing list
>> Fail2ban-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users
------------------------------------------------------------------------------
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic