Assigning to all packagers collectively, since there is no registered maintainer for this package.

CC: (none) => marja11
Assignee: bugsquad => pkg-bugs

Suggested advisory:
========================

The updated package fixes a security vulnerability:

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. (CVE-2021-32749)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32749
https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/RYBYCPVAMLJBPZO42ZMSVOQTCNN3YNQS/
https://bugzilla.suse.com/show_bug.cgi?id=1188610
https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm
========================

Updated package in core/updates_testing:
========================
fail2ban-0.11.2-1.1.mga8

from SRPM:
fail2ban-0.11.2-1.1.mga8.src.rpm

Assignee: pkg-bugs => qa-bugs
Whiteboard: MGA8TOO => (none)
Version: Cauldron => 8
Status: NEW => ASSIGNED
Status comment: Fixed upstream in 0.11.3 => (none)
CVE: (none) => CVE-2021-32749
Source RPM: fail2ban-0.11.2-2.mga9.src.rpm => fail2ban-0.11.2-1.mga8.src.rpm
CC: (none) => nicolas.salguero

MGA8-64 Plasma on Lenovo B50
No installation issues.
at CLI:
# systemctl status fail2ban
● fail2ban.service - fail2ban attack scanner
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled)
     Active: inactive (dead)

# systemctl start fail2ban

# systemctl status fail2ban
● fail2ban.service - fail2ban attack scanner
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-09-23 14:23:52 CEST; 3s ago
    Process: 11290 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=0/SUCCESS)
   Main PID: 11293 (fail2ban-server)
      Tasks: 3 (limit: 9402)
     Memory: 9.8M
        CPU: 207ms
     CGroup: /system.slice/fail2ban.service
             └─11293 /usr/bin/python3 -s /usr/bin/fail2ban-server --async -b -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x --loglevel INFO --logtarget /var/log/fai>

sep 23 14:23:52 mach5.hviaene.thuis systemd[1]: Starting fail2ban attack scanner...
sep 23 14:23:52 mach5.hviaene.thuis fail2ban-client[11290]: Server ready
sep 23 14:23:52 mach5.hviaene.thuis systemd[1]: Started fail2ban attack scanner.


So at least the default config seems to run OK.
Now ref bugs 11569 and 10550 for testing.
Claire refers in /etc/fail2ban/jail.conf to a section

[ssh-iptables]

enabled  = false
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=you@example.com, sender=fail2ban@examp$
logpath  = /var/log/auth.log

But I don't see anything like that in the conf file.
Googled and found a tutorial but that's one from 2015, so probably obsolete.
Found https://www.youtube.com/watch?v=kgdoVeyoO2E and now trying to follow that one. Coming back later.

CC: (none) => herman.viaene

Leaned that changes should be made in /etc/fail2ban/jail.local, intitially a copy of /etc/fail2ban/jail.conf.
As I read Claire's procedure and follow the video I change the section for sshd to:
[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal
enabled = true
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
After making sure that the sshd runs, I restart fail2ban:
# systemctl start fail2ban
Job for fail2ban.service failed because the control process exited with error code.
See "systemctl status fail2ban.service" and "journalctl -xe" for details.

# systemctl -l status fail2ban
● fail2ban.service - fail2ban attack scanner
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Thu 2021-09-23 15:56:57 CEST; 6s ago
    Process: 17827 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=255/EXCEPTION)
        CPU: 116ms

sep 23 15:56:57 mach5.hviaene.thuis systemd[1]: Starting fail2ban attack scanner...
sep 23 15:56:57 mach5.hviaene.thuis fail2ban-client[17827]: 2021-09-23 15:56:57,357 fail2ban                [17827]: ERROR   Failed during configuration: Have not found any log file for sshd jail
sep 23 15:56:57 mach5.hviaene.thuis systemd[1]: fail2ban.service: Control process exited, code=exited, status=255/EXCEPTION
sep 23 15:56:57 mach5.hviaene.thuis systemd[1]: fail2ban.service: Failed with result 'exit-code'.
sep 23 15:56:57 mach5.hviaene.thuis systemd[1]: Failed to start fail2ban attack scanner.

What this "log file for sshd jail" might be, I haven't got a clue. cou this be because I installed sshd after installing fail2ban. Continuing.......

Removing fail2ban completely (manually deleting /etc/fail2ban), make sure sshd is running and reinstall fail2ban. Same failure on missing log file.
Did some more reading and found that the openssh-server does not include any log file.
Changed two things:
1. added /var/log/sshd folder
2. edited the log entry for sshd in jail.local to
logpath = /var/log/sshd
Then
# systemctl start fail2ban
# systemctl -l status fail2ban
● fail2ban.service - fail2ban attack scanner
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-09-23 16:25:14 CEST; 6s ago
    Process: 20570 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=0/SUCCESS)
   Main PID: 20573 (fail2ban-server)
      Tasks: 3 (limit: 9402)
     Memory: 10.4M
        CPU: 262ms
     CGroup: /system.slice/fail2ban.service
             └─20573 /usr/bin/python3 -s /usr/bin/fail2ban-server --async -b -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x --loglevel INFO --logtarget /var/log/fail2ban.log --syslogsocke>

sep 23 16:25:14 mach5.hviaene.thuis systemd[1]: Starting fail2ban attack scanner...
sep 23 16:25:14 mach5.hviaene.thuis fail2ban-client[20570]: 2021-09-23 16:25:14,954 fail2ban                [20570]: ERROR   NOK: (21, 'Is a directory')
sep 23 16:25:14 mach5.hviaene.thuis fail2ban-client[20570]: Server ready
sep 23 16:25:14 mach5.hviaene.thuis systemd[1]: Started fail2ban attack scanner.
[root@mach5 ~]# fail2ban-client status
Status
|- Number of jail:      1
`- Jail list:   sshd

So now fail2ban runs and reports there is a sshd jail active.
Is that conclusive enugh for this test, because I doubt the openssh-server will ever log anything in the log folder.

@Herman in reply to comment 5.
Not qualified to comment but having watched the video and looked over your shoulder it seems like you have got it working OK.  As you say, nothing is going to appear in the log files unless there is a real or simulated attack.

CC: (none) => tarazed25

I know even less about this stuff than you two do, but I watched the video, too. It sounds like this is highly configurable, so testing for all functions is beyond the scope of QA.

It looks to me like you've shown basic functionality, at the very least, so I'm going to OK it. Validating. Advisory in Comment 2.

CC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (none) => MGA8-64-OK

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0464.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED