Menu

#11 Patch for iptables issues when adding rules parallel

open
nobody
None
5
2009-09-11
2009-09-11
idl0r
No

Hey guys,

I had some issues with fail2ban when running more than 1 jail.
So I wrote a patch or even workaround to get all chains into iptables.
It might be good enough to apply it into the next release but thats up to you... maybe you guys are able to find a better solution since I didn't spent much time into it.

Discussion

  • idl0r

    idl0r - 2009-09-11

    action.py.patch

     
  • Michael Geiger

    Michael Geiger - 2009-10-01

    Hi idl0r, thanks for your patch - I nearly got crazy with this bug ...

     
  • Yaroslav Halchenko

    This patch unfortunately breaks commands with multiline string arguments in them (e.g. sending an email notifications).
    Original problem is with concurrent execution of iptables commands by separate threads (there is 1 thread per jail in fail2ban) upon jail initiation. Possible solution is to sleep some random amount of time before executing the command. It could be accomplished with adding smth like

    sleep ${RANDOM:0:1}.${RANDOM: -1:1}

    to the beginning of actionstart/actionstop if you use bash for your shell

     
  • Yaroslav Halchenko

    For more details see http://bugs.debian.org/554162

     
  • Jonathan Underwood

    The fix with adding random sleeps is a workaround, but not the right long term fix. It's a design flaw to have the action{start,stop} executing in parallel IMO. Either they should be serialized, or a locking mechanism put in place to ensure that multiline commands are treated atomicly.

     
  • Anonymous

    Anonymous - 2010-11-18

    could you or someone please be a bit more specific i am experiencing this bug but cannot get it fixed by patching (indeed because of broken lines) and i do not understand how next patch is applied, because i don't know python

    "Possible solution is to sleep some random amount of time before
    executing the command. It could be accomplished with adding smth like

    sleep ${RANDOM:0:1}.${RANDOM: -1:1}

    to the beginning of actionstart/actionstop if you use bash for your shell"

     
  • Anonymous

    Anonymous - 2011-09-20

    I came up with a slightly different approach to fixing this bug. I changed executeCmd() to a classmethod instead of a staticmethod. I also created a lock as a class variable, which prevents two calls to os.system from running in parallel from any instance of the Action class. It is perhaps not the prettiest solution, but it is a very small change and I believe it addresses the root of the problem without causing any side effects.

    I just modified the file in place on my system, but I can create and post a patch if anyone is interested.

     

Log in to post a comment.