* 'Support_for_mysql_log_example' of https://github.com/arto-p/fail2ban:
Added testcase for MySQL date format to testcases/datedetectortestcase.py and example of MySQL log file.
Added support for MySQL logfiles
Conflicts:
testcases/datedetectortestcase.py -- conflictde with other added test cases
* 001-fail2ban-server-socket-close-on-exec-no-leak.diff
Add code that marks server and client sockets with FD_CLOEXEC flags.
Avoid leaking file descriptors to processes spawned when handling
fail2ban actions (ex: iptables).
Unix sockets managed by fail2ban-server don't need to be passed to any
child process. Fail2ban already uses the FD_CLOEXEC flags in the filter
code.
This patch also avoids giving iptables access to fail2ban UNIX socket in
a SELinux environment (A sane SELinux policy should trigger an audit
event because "iptables" will be given read/write access to the fail2ban
control socket).
Some random references related to this bug:
http://sourceforge.net/tracker/?func=detail&atid=689044&aid=2086568&group_id=121032http://www.redhat.com/archives/fedora-selinux-list/2009-June/msg00124.htmlhttp://forums.fedoraforum.org/showthread.php?t=234230
* 002-fail2ban-filters-close-on-exec-typo-fix.diff
There is a typo in the fail2ban server/filter.py source code. The
FD_CLOEXEC is correctly set but additional *random* flags are also set.
It has no side-effect as long as the fd doesn't match a valid flag :)
"fcntl.fcntl(fd, fcntl.F_SETFD, fd | fcntl.FD_CLOEXEC)" <== the 3rd
parameter should be flags, not a file descriptor.
* 003-fail2ban-gamin-socket-close-on-exec-no-leak.diff
Add code that marks the Gamin monitor file descriptor with FD_CLOEXEC
flags. Avoid leaking file descriptors to processes spawned when handling
fail2ban actions (ex: iptables).
---
File descriptors in action process before patches:
dr-x------ 2 root root 0 .
dr-xr-xr-x 8 root root 0 ..
lr-x------ 1 root root 64 0 -> /dev/null <== OK
l-wx------ 1 root root 64 1 -> /tmp/test.log <== used by test action
lrwx------ 1 root root 64 2 -> /dev/null <== OK
lrwx------ 1 root root 64 3 -> socket:[116361] <== NOK (fail2ban.sock leak)
lr-x------ 1 root root 64 4 -> /proc/20090/fd <== used by test action
l-wx------ 1 root root 64 5 -> /var/log/fail2ban.log <== OK
lrwx------ 1 root root 64 6 -> socket:[115608] <== NOK (gamin sock leak)
File descriptors in action process after patches:
dr-x------ 2 root root 0 .
dr-xr-xr-x 8 root root 0 ..
lr-x------ 1 root root 64 0 -> /dev/null <== OK
l-wx------ 1 root root 64 1 -> /tmp/test.log <== used by test action
lrwx------ 1 root root 64 2 -> /dev/null <== OK
lr-x------ 1 root root 64 3 -> /proc/18284/fd <== used by test action
l-wx------ 1 root root 64 5 -> /var/log/fail2ban.log <== OK
Now it should be evaluated only if logging mode is debug or "lower", and also
should happen not only on initial detections but for every added failure.
It also reports counts per each IP now
* 'master' of https://github.com/sebres/fail2ban:
invalid date recognition, irregular because of sorting template list, now via setRegex
invalid date recognition, irregular because of sorting template list (sometimes not reproducible by fail2ban-regex, cause will be not sorted)
* 'datedetector-testcase' of https://github.com/kwirk/fail2ban:
Correct datedetector testcases for TAI64N format
Additional date/time formats for datedetector testcases
Also made a note that some workarounds for certain date/time formats
may cause week/year day to be incorrect. This does not affect
functionality of fail2ban so no urgency to fix.
date in following log line (from nginx) will be wrong detected:
2012/10/11 02:37:17 [error] 18434#0: *947 user "test" was not found in "/www/...", client: 192.168.1.5, ...
sometimes it is [correct] - 2012/10/11 (%Y/%m/%d) = 1349919861.71
sometimes it is [invalid] - 12/10/11 (%d/%m/%y) = 1349915838.06
and older as now - 1800 seconds (therefore will be not found)
solution: regular expression fixed, cause date in log used always after non symbol (\W) character, so r"\d{2}/\d{2}/\d{2}" will be r"(?<!\w)\d{2}/\d{2}/\d{2}".
Before, it would first do stable sort followed with explicit reverse.
Now reverse is given as an argument to sort, and it results in actually
preserving the order in case of e.g. no sorting needed
Otherwise it might lead to spurious characters dumped into the
terminal at few places, unless casted upon every use in the logs. To
prevent those issues in the source, store IP as a basic string if it
is a string at all
Steven Hiscocks