On Tue, Oct 04, 2005 at 03:18:27PM -0400, Yaroslav Halchenko wrote: > On Tue, Oct 04, 2005 at 11:29:45AM -0700, Ross Boylan wrote: > > concerns the program operation and endless loop. This one concerns > > primarily user information (which may have been addressed) and the > > problem that the firewall rules become ineffective if the main INPUT > > chain is altered so at to deleted the references to the fail2ban > > rules. > yeap -- and that would lead to the absent chain, all failed login > attempts will continue to flow, fail2ban will disregard them because it > thinks that they are banned, unban will fail because there is no chain, > and infinite loop situation can occur > Is that right?
I'm probably not aware of all the implications of different misconfigurations, but I thought 329163 was about the problems that happen if, for example, fail2ban-ssh is missing. In contrast, in the case I'm thinking of, fail2ban-ssh (the table) is present, but there are no references to it from the INPUT table. > > The both bugs are grown from the same fact that if a user ( or > outside of fail2ban firewal etc) changes iptables INPUT chain, fail2ban > cannot function properly. In both cases fail2ban won't function, but it might fail in different ways (e.g., in the case I'm thinking of, "banned" IP's continue to have access; in 329163 that's true, but in addition you get infinite loops and resource problems). Also, in this case I'm definitely focused on INPUT being altered, while I thought the other case concerned the fail2ban-ssh table being non-existent. My understanding of 329163, or even the consequences of the scenario I describe, may be faulty. I agree that both problems arise from the general category "somebody messes with the tables after fail2ban runs." > > During startup fail2ban starts up after networking and all firewalls > (which supposed to be started from /etc/rcS.d/ if I'm not wrong) so > general user should be fine as far as he doesn't restart the firewall or > wipes out INPUT manually. Good. That's reassuring. > > > In other words, 329163 is about infinite loops, while this concerns > > failure to run at all. > Otherwise, If something like that happens, fail2ban renders unusable > and might loop endlessly. That is why I considered both bug reports to > be the same because the source of the problem is the same. > > > Also, this bug/wish has some ideas about program functionality. You > > may or may not wish to pursue those ideas. > indeed. we had an idea to include a check for existing chain before every > operation with iptables... for now we just limited the solution by the > note in README.Debian. Hopefully soon (if there will be not that many > bug reports) recent fail2ban will get into testing, thus the others will > see that note :-) This wish was mostly for some more documentation, so if it's already done my wish has been granted :) Ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
