Описание
Security update for fail2ban
This update for fail2ban fixes the following issues:
-
CVE-2021-32749: prevent a command injection via mail command (boo#1188610)
-
Integrate change to resolve boo#1146856 and boo#1180738
Update to 0.11.2
- increased stability, filter and action updates
New Features and Enhancements
- fail2ban-regex:
- speedup formatted output (bypass unneeded stats creation)
- extended with prefregex statistic
- more informative output for
datepattern(e. g. set from filter) - pattern : description
- parsing of action in jail-configs considers space between action-names as separator also
(previously only new-line was allowed), for example
action = a bwould specify 2 actionsaandb - new filter and jail for GitLab recognizing failed application logins (gh#fail2ban/fail2ban#2689)
- new filter and jail for Grafana recognizing failed application logins (gh#fail2ban/fail2ban#2855)
- new filter and jail for SoftEtherVPN recognizing failed application logins (gh#fail2ban/fail2ban#2723)
filter.d/guacamole.confextended withloggingparameter to follow webapp-logging if it's configured (gh#fail2ban/fail2ban#2631)filter.d/bitwarden.confenhanced to support syslog (gh#fail2ban/fail2ban#2778)- introduced new prefix
{UNB}fordatepatternto disable word boundaries in regex; - datetemplate: improved anchor detection for capturing groups
(^...); - datepattern: improved handling with wrong recognized timestamps (timezones, no datepattern, etc)
as well as some warnings signaling user about invalid pattern or zone (gh#fail2ban/fail2ban#2814):
- filter gets mode in-operation, which gets activated if filter starts processing of new messages;
in this mode a timestamp read from log-line that appeared recently (not an old line), deviating too much
from now (up too 24h), will be considered as now (assuming a timezone issue), so could avoid unexpected
bypass of failure (previously exceeding
findtime); - better interaction with non-matching optional datepattern or invalid timestamps;
- implements special datepattern
{NONE}- allow to find failures totally without date-time in log messages, whereas filter will use now as timestamp (gh#fail2ban/fail2ban#2802)
- filter gets mode in-operation, which gets activated if filter starts processing of new messages;
in this mode a timestamp read from log-line that appeared recently (not an old line), deviating too much
from now (up too 24h), will be considered as now (assuming a timezone issue), so could avoid unexpected
bypass of failure (previously exceeding
- performance optimization of
datepattern(better search algorithm in datedetector, especially for single template); - fail2ban-client: extended to unban IP range(s) by subnet (CIDR/mask) or hostname (DNS), gh#fail2ban/fail2ban#2791;
- extended capturing of alternate tags in filter, allowing combine of multiple groups to single tuple token with new tag
prefix
<F-TUPLE_, that would combine value of<F-V>with all value of<F-TUPLE_V?_n?>tags (gh#fail2ban/fail2ban#2755)
- Fixes
- [stability] prevent race condition - no ban if filter (backend) is continuously busy if too many messages will be found in log, e. g. initial scan of large log-file or journal (gh#fail2ban/fail2ban#2660)
- pyinotify-backend sporadically avoided initial scanning of log-file by start
- python 3.9 compatibility (and Travis CI support)
- restoring a large number (500+ depending on files ulimit) of current bans when using PyPy fixed
- manual ban is written to database, so can be restored by restart (gh#fail2ban/fail2ban#2647)
jail.conf: don't specifyactiondirectly in jails (useaction_orbanactioninstead)- no mails-action added per default anymore (e. g. to allow that
action = %(action_mw)sshould be specified per jail or in default section in jail.local), closes gh#fail2ban/fail2ban#2357 - ensure we've unique action name per jail (also if parameter
actnameis not set but name deviates from standard name, gh#fail2ban/fail2ban#2686) - don't use
%(banaction)sinterpolation because it can be complex value (containing[...]and/or quotes), so would bother the action interpolation - fixed type conversion in config readers (take place after all interpolations get ready), that allows to specify typed parameters variable (as substitutions) as well as to supply it in other sections or as init parameters.
action.d/*-ipset*.conf: several ipset actions fixed (no timeout per default anymore), so no discrepancy between ipset and fail2ban (removal from ipset will be managed by fail2ban only, gh#fail2ban/fail2ban#2703)action.d/cloudflare.conf: fixedactionunban(considering new-line chars and optionally real json-parsing withjq, gh#fail2ban/fail2ban#2140, gh#fail2ban/fail2ban#2656)action.d/nftables.conf(type=multiport only): fixed port range selector, replacing:with-(gh#fail2ban/fail2ban#2763)action.d/firewallcmd-*.conf(multiport only): fixed port range selector, replacing:with-(gh#fail2ban/fail2ban#2821)action.d/bsd-ipfw.conf: fixed selection of rule-no by large list or initiallowest_rule_num(gh#fail2ban/fail2ban#2836)filter.d/common.conf: avoid substitute of default values in relatedlt_*section,__prefix_lineshould be interpolated in definition section (inside the filter-config, gh#fail2ban/fail2ban#2650)filter.d/dovecot.conf:- add managesieve and submission support (gh#fail2ban/fail2ban#2795);
- accept messages with more verbose logging (gh#fail2ban/fail2ban#2573);
filter.d/courier-smtp.conf: prefregex extended to consider port in log-message (gh#fail2ban/fail2ban#2697)filter.d/traefik-auth.conf: filter extended with parameter mode (normal,ddos,aggressive) to handle the match of username differently (gh#fail2ban/fail2ban#2693):normal: matches 401 with supplied username onlyddos: matches 401 without supplied username onlyaggressive: matches 401 and any variant (with and without username)
filter.d/sshd.conf: normalizing of user pattern in all RE's, allowing empty user (gh#fail2ban/fail2ban#2749)
Update to 0.11.1:
- Increment ban time (+ observer) functionality introduced.
- Database functionality extended with bad ips.
- New tags (usable in actions):
<bancount>- ban count of this offender if known as bad (started by 1 for unknown)<bantime>- current ban-time of the ticket (prolongation can be retarded up to 10 sec.)
- Introduced new action command
actionprolongto prolong ban-time (e. g. set new timeout if expected); - algorithm of restore current bans after restart changed: update the restored ban-time (and therefore end of ban) of the ticket with ban-time of jail (as maximum), for all tickets with ban-time greater (or persistent)
- added new setup-option
--without-teststo skip building and installing of tests files (gh-2287). - added new command
fail2ban-client get <JAIL> banip ?sep-char|--with-time?to get the banned ip addresses (gh-1916). - purge database will be executed now (within observer). restoring currently banned ip after service restart fixed (now < timeofban + bantime), ignore old log failures (already banned)
- upgrade database: update new created table
bipswith entries from tablebans(allows restore current bans after upgrade from version <= 0.10)
- removal of SuSEfirewall2-fail2ban for factory versions since SuSEfirewall2 will be removed from Factory (see sr#713247):
- removed references to SuSEfirewall2 service
- use references to SuSEfirewall2 only for older distributions
- Removed installation recommendation of the fail2ban-SuSEfirewall2 package for all distributions as it is deprecated.
- changed fail2ban unit file location (boo#1145181, gh#fail2ban/fail2ban#2474)
Список пакетов
SUSE Package Hub 15 SP1
SUSE Package Hub 15 SP2
SUSE Package Hub 15 SP3
openSUSE Leap 15.2
openSUSE Leap 15.3
Ссылки
- E-Mail link for openSUSE-SU-2021:1274-1
- SUSE Security Ratings
- SUSE Bug 1145181
- SUSE Bug 1146856
- SUSE Bug 1180738
- SUSE Bug 1188610
- SUSE CVE CVE-2021-32749 page
Описание
fail2ban is a daemon to ban hosts that cause multiple authentication errors. In versions 0.9.7 and prior, 0.10.0 through 0.10.6, and 0.11.0 through 0.11.2, there is a vulnerability that leads to possible remote code execution in the mailing action mail-whois. Command `mail` from mailutils package used in mail actions like `mail-whois` can execute command if unescaped sequences (`\n~`) are available in "foreign" input (for instance in whois output). To exploit the vulnerability, an attacker would need to insert malicious characters into the response sent by the whois server, either via a MITM attack or by taking over a whois server. The issue is patched in versions 0.10.7 and 0.11.3. As a workaround, one may avoid the usage of action `mail-whois` or patch the vulnerability manually.
Затронутые продукты
Ссылки
- CVE-2021-32749
- SUSE Bug 1188610