Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"enabled=auto" to enable jail if the log file present #55

Open
yarikoptic opened this issue May 21, 2012 · 3 comments

Comments

Projects
None yet
4 participants
@yarikoptic
Copy link
Member

commented May 21, 2012

Should be really easy to implement AFAIK

Related reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407404

@kwirk

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2013

Just some thoughts on this idea:

For some jails you will have log files present, even without the service, e.g. auth.log with sshd(but standard for pam/su, etc), mail.log for postfix/courier/dovecot/cyrus, etc.

Therefore, maybe there needs to be a way for a jail (or filter) to have a "serviceregex" or the like, such that if matched it will start the jail. e.g. for ssh sshd\[\d+\]: Server listening on .+$.
Issues with this is you may end up in a situation where fail2ban starts before the service, and misses the relevant entry.

How about when a service is started but not as part of boot? You could go down the route of having a separate thread which monitors all the auto detect log files, and checks to see if a service has started. I think this maybe a bit OTT. Maybe this thread could run for the first 5 minutes from fail2ban's start to stop the race condition mentioned in previous paragraph.

@grooverdan

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2014

serviceregex is definitely a useful idea.

Given the range of logging options for services that can switch between syslog and its own log file this isn't really trivial at all. A way I thought of is for each filter an autodetect command option that returns a list of log files (and ports?) after some check that the right processes are running and any other checks on the processes configuration. Perhaps also some abbreviation for syslog:daemon that has some distro hint as to which file.

Does journald solve this for the future? Not that I could see (but bits where getting a little complicated).

@yarikoptic yarikoptic modified the milestones: 0.9.1, 0.9.0 Apr 16, 2014

@kwirk kwirk modified the milestones: 0.9.2, 0.9.1 May 7, 2014

@yarikoptic yarikoptic modified the milestones: 0.9.2, 0.9.3 Feb 14, 2015

@yarikoptic yarikoptic modified the milestones: 0.9.3, 0.9.4 Jul 11, 2015

@yarikoptic yarikoptic modified the milestones: 0.9.4, 0.9.5 Jan 8, 2016

@yarikoptic yarikoptic modified the milestones: 0.9.5, 0.9.6 Jul 16, 2016

@yarikoptic yarikoptic modified the milestones: 0.9.6, 0.9.7 Dec 9, 2016

@sebres

This comment has been minimized.

Copy link
Member

commented Mar 13, 2017

Just to link it with #1379

BTW. This may be too grave for all possible logs (at least if someone will set "enabled=auto" in default section of jail.local), because too many threads will be created (and our current handling is a polling).
I've an observer thread in #1460 (that opposite to jail threads is completely event-driven). If we could rewrite fail2ban to use a thread pool of such event-driven threads (instead of 2 threads per jail)...
Just as an idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.