Bug#331695: fail2ban: Note possible need to modify firewall rules
Package: fail2ban Version: 0.5.2-4 Severity: wishlist It would be good to note that if the user has or modifies the INPUT chain they will need to include rules (and their names) to keep fail2ban working. I didn't appreciate this and accidentally disabled it. Also, I'm not sure if the rules will be in place properly if one restarts the system. I gather the fail2ban daemon inserts appropriate rules into the INPUT chain (do I mean table?), but I'm not sure how the timing of that works out relative to other spots the user might set firewall rules (e.g., via /etc/network/interfaces or other scripts). The desirable behavior is not clear to me. On the one hand, if fail2ban starts late, the firewall rules are likely to be around, and it's less likely fail2ban's rule will be overwritten. That seems good, particularly because someone who just installs it will have a working system. On the other hand, if someone wants to control exactly where the fail2ban rules are activated, they will want to install the rules manually and not have fail2ban and a potential duplicate at another position. Possible solutions: add a config and startup option to control whether fail2ban rewrites INPUT. Or scan the existing INPUT table to see if a reference to the fail2ban-xxx chain is already present, and insert the reference only if it is missing. The minimalist solution is just documenting what's going on and leaving it to the administrator to be sure things are OK. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (990, 'stable'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27advncdfs Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages fail2ban depends on: ii iptables 1.3.3-2Linux kernel 2.4+ iptables adminis ii python2.3.5-3An interactive high-level object-o fail2ban recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331695: fail2ban: Note possible need to modify firewall rules
Would you mind me merging this bug with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329163 ? they seems to be about the same problem or I misinterpreted it? and btw note about it is included in README.Debian since 0.5.2-5 :-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpovE4gHU2dI.pgp Description: PGP signature
Bug#331695: fail2ban: Note possible need to modify firewall rules
On Tue, Oct 04, 2005 at 02:17:29PM -0400, Yaroslav Halchenko wrote: Would you mind me merging this bug with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329163 ? they seems to be about the same problem or I misinterpreted it? It's in the same neighborhood, but a different building. That bug 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. In other words, 329163 is about infinite loops, while this concerns failure to run at all. Also, this bug/wish has some ideas about program functionality. You may or may not wish to pursue those ideas. and btw note about it is included in README.Debian since 0.5.2-5 :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331695: fail2ban: Note possible need to modify firewall rules
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? 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. 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. 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 :-) -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgphv2TYMRIIp.pgp Description: PGP signature
Bug#331695: fail2ban: Note possible need to modify firewall rules
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]
Bug#331695: fail2ban: Note possible need to modify firewall rules
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. You do have deeper understanding of the problem and outcomes than I do ;-) I didn't bother to bisect the problem in two (missing fail2ban chaing, missing -j to the chain) because either of them is bad. You are 100% right that outcomes are different, but I think that the solution to both bug reports should come as a 1 piece ;-) 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. 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 :) I might adjust README.Debian to reflect the two-fold problem as you brought it up. So, in any way, discussion was useful - thank you. I will merge this bug with #329163 so we the issue open till we fix it in a proper way -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] pgpp0OzKUNzTn.pgp Description: PGP signature
