* _enh/test_backends:
RF: reordered tests + enabled gamin now that its fix is pending in Debian
ENH+BF: filtergamin -- to be more inline with current design of filterinotify
ENH: 1 more sleep_4_poll to guarantee difference in time stamp
ENH: few more delays for cases relying on time stamps
ENH: tests much more robust now across pythons 2.4 -- 2.7
BF+RF: pyinotify refreshes watcher upon CREATE, unified/simplified *(add|del)LogPath among *Filters
ENH: fail2ban-testcases -- custom logging format to ease debugging, non-0 exit code in case of failure
ENH: Filter's testcases -- rename, del + list again --- a bit unstable, might still fail from time to time
BF: pyinotify -- monitor the parent directory for IN_CREATE + process freshly added file (Closes gh-44)
ENH: first working unittest for checking polling and inotify backends
RF/BF: just use pyinotify.ThreadedNotifier thread in filterpyinotify
RF: filter.py -- single readline in a loop
ENH: FilterPoll -- adjusted some msgs + allowed to operate without jail (for testing)
Minor additional comment to DEVELOP
ENH: extended test LogfileMonitor
* needed additional sleeps for polling filter since that one relies on
time-stamps and too rapid changes would not be caught by the
PollFilter
* in python 2.4, time stamps are up to a second (int's) so sleeps longer
* test_new_bogus_file -- just to make sure that addition of new files
does not alter our monitoring
* all of the *Filters had too much of common logic in their *LogPath
methods, which is now handled by FileFilter and derived classes only
add custom actions in corresponding _(add|del)LogPath methods
pyinotify:
* upon CREATE event:
- unknown files should not be handled at all
- "watcher" for the monitored files should be recreated.
Lead to adding _(add|del)FileWatcher helper methods
* callback now obtains full event to judge what to do
Noticed while looking at the source (to see the point of ssh-ddos).
POSSIBLE BREAK-IN ATTEMPT - sounds scary? But keep reading
the message. It's not a login failure. It's a warning about
reverse-DNS. The login can still succeed, and if it _does_ fail,
that will be logged as normal.
<exhibit n="1">
Jul 9 05:43:00 brick sshd[18971]: Address 200.41.233.234 maps to host234.advance.com.
ar, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Jul 9 05:43:00 brick sshd[18971]: Invalid user html from 200.41.233.234
</exhibit>
The problem (in my mind) is that some users are stuck with bad dns.
The warning won't stop them from logging in. I'm pretty sure they can't
even see it. But when they exceed a threshold number of logins -
which could be all successful logins - fail2ban will trigger.
fail2ban shouldn't adding additional checks to successful logins
- it goes against the name fail2ban :)
- the first X "POSSIBLE BREAK-IN ATTEMPT"s would be permitted anyway
- if you want to ban bad DNS, the right way is PARANOID in /etc/hosts.deny
I've checked the source of OpenSSH, and this will only affect the
reverse-DNS error. (I won't be offended if you want to check
for yourself though ;)
<exhibit n="2">
$ grep -r -h -C1 'ATTEMPT' openssh-5.5p1/
logit("reverse mapping checking getaddrinfo for %.700s "
"[%s] failed - POSSIBLE BREAK-IN ATTEMPT!", name, ntop);
return xstrdup(ntop);
--
logit("Address %.100s maps to %.600s, but this does not "
"map back to the address - POSSIBLE BREAK-IN ATTEMPT!",
ntop, name);
$
</exhibit>
* gh-magicrhesus/master:
Add the INCLUDE section to use __pid_re feature
Disable asterisk jail by default
Change jail for asterisk, add support for SIP and SIP-TLS on TCP and UDP ports
Change NOTICE by NOTICE%(__pid_re)s
Remove custom bantime
Add sample log file for asterisk
Add $ at the end of the failregex
Add asterisk support
Conflicts:
config/jail.conf -- placed asterisk jails before recidive and added blank lines after the jail headers
