Talk:FEATURE Split config
File Structure
just for historic reasons: excerpt from our ICQ conversation:
->
ok -- be it /etc/fail2ban/{fail2ban{.local,}.conf,{action,filter}s.d/*} ?
<-
j'approuve
I also look back at our ICQ conversation. I think this is the right way to go. --Lostcontrol 01:38, 17 May 2006 (PDT)
Jails
I don't see sense in jail.d directory: my suggestion is simply to have 2 config parameters within fail2ban.conf
default_actions and jails (multiline)
examples:
default_actions=mail-smtp iptables
jails=%(default_actions)s ssh
%(default_actions)s apache
mail-postfixadmin postfix
hostsdeny rlogin
fail2ban.local of cause could easily override those parameters
This is a good idea. I remember you were talking about a symlink solution. Any comments on this? I just think it would be better to put filter first and then action(s).
examples:
default_actions=mail-smtp iptables
jails=ssh %(default_actions)s
apache %(default_actions)s
postfix mail-postfixadmin
rlogin hostsdeny
--Lostcontrol 01:38, 17 May 2006 (PDT)
May be I just need to rest but I've started to think about making it a bit more flexible:
- the same filter can be present in multiple jails with different parameters
- different filters can be combined to create "and" rule, so if both of them trigger, action is taken
jails=ssh %(default_actions)s
ssh[maxfailures=10,findtime=6000] iptables[bantime=-1]
ssh apache iptables[bantime=-1,port=all]
May be combined filters overkill... probably it should be implemented on higher level by some policy-based intrusion system based on fail2ban logs... --Yarik 15:38, 3 July 2006 (PDT)
Sure - this way might be cleaner, but should be functionally the same ;-)
As for symlinks -- since we decided to make arbitrary combinations of filter+actions I don't see how symlinks would help. In my experimental attempt with split files I just had filters.enabled/ with symlinks to filters.available/ where each file was just a filter. For combinations I think it would not be worth
Since you agree - I am removing jail.d from the split configuration
--Yarik 07:46, 17 May 2006 (PDT)
Sections
I see next types of sections within the configuration (as you pointed out by the split already)
- filter
- action
the question is either mail-smtp (as what MAIL is now) should be separate kind like now and use internal python's SMTP client or we can rely on external, then it could be easily unified into "action" class. mail-mta is the one which easily can be implemented within "action" class when we rely on the present on the system MTA and mail command.
I wanted to remove the mail.py class and use Python logging instead. Logging can also send e-mails and thus, we would have a unified notification/logging system. However, I prefer your solution which avoid adding code into Fail2ban and take advantage of "multiactions". --Lostcontrol 01:38, 17 May 2006 (PDT)
