root@DietPi:# systemctl restart fail2ban
Job for fail2ban.service failed because the control process exited with error co de.
See "systemctl status fail2ban.service" and "journalctl -xe" for details.
root@DietPi:# systemctl status fail2ban.service
โ fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; disabled; vendor preset
: enabled)
Active: activating (start) since Mon 2018-01-29 13:09:11 GMT; 1s ago
Docs: man:fail2ban(1)
Cntrl PID: 2647 (fail2ban-client)
CGroup: /system.slice/fail2ban.service
โโ2647 /usr/bin/python3 /usr/bin/fail2ban-client -x start
Jan 29 13:09:11 DietPi systemd[1]: Starting Fail2Ban Service...
Jan 29 13:09:13 DietPi fail2ban-client[2647]: WARNING 'syslogsocket' not defined
in 'Definition'. Using default one: 'auto'
Jan 29 13:09:13 DietPi fail2ban-client[2647]: WARNING 'dbfile' not defined in 'D
efinition'. Using default one: '/var/lib/fail2ban/fail2ban.sqlite3'
Jan 29 13:09:13 DietPi fail2ban-client[2647]: WARNING 'dbpurgeage' not defined i
n 'Definition'. Using default one: 86400
Jan 29 13:09:13 DietPi fail2ban-client[2647]: WARNING 'filter' not defined in 's
shd'. Using default one: ''
Jan 29 13:09:13 DietPi fail2ban-client[2647]: WARNING No filter set for jail ssh
d
Jan 29 13:09:13 DietPi fail2ban-client[2647]: WARNING 'filter' not defined in 's
shd'. Using default one: ''
Jan 29 13:09:13 DietPi fail2ban-client[2647]: ERROR Failed during configuration
: Bad value substitution: option 'action' in section 'sshd' contains an interpolation key 'port' which is
not a valid option name. Raw value: '%(action_)s'
@MichaIng
I'll pick this one up, unless you've started?
@Fourdee
๐ As it seems RPi specific, I can't test it here fast.
Just remembered the old fail2ban issue on Debian Stretch Status issue, and that we did not fix the RPi specific issue there, just the general Stretch issue with non-existent /var/log/auth.log.
One report there lead me to this: https://github.com/Fourdee/DietPi/issues/1428#issuecomment-361235269 Doubled port declaration should not make sense of course.
But sadly doesn't seem to be the (only) issue of Saxndi.
Notes:
โ fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; disabled; vendor preset
: enabled)
Active: failed (Result: exit-code) since Mon 2018-01-29 14:50:24 G
MT; 10min ago
Docs: man:fail2ban(1)
Process: 28461 ExecStart=/usr/bin/fail2ban-client -x start (code=exite
d, status=255)
Jan 29 14:50:24 DietPi systemd[1]: fail2ban.service: Unit entered failed
state.
Jan 29 14:50:24 DietPi systemd[1]: fail2ban.service: Failed with result
'exit-code'.
Jan 29 14:50:24 DietPi systemd[1]: fail2ban.service: Service hold-off time over,
scheduling restart.
Jan 29 14:50:24 DietPi systemd[1]: Stopped Fail2Ban Service.
Jan 29 14:50:24 DietPi systemd[1]: fail2ban.service: Start request repea
ted too quickly.
Jan 29 14:50:24 DietPi systemd[1]: Failed to start Fail2Ban Service.
Jan 29 14:50:24 DietPi systemd[1]: fail2ban.service: Unit entered failed
state.
Jan 29 14:50:24 DietPi systemd[1]: fail2ban.service: Failed with result
'exit-code'.
root@DietPi:~# /usr/bin/fail2ban-client -x start
ERROR Failed during configuration: While reading from '/etc/fail2ban/jail.conf' [line 52]: option 'port' in section 'pam-generic' already exists
Issue due to outdated /etc/fail2ban/jail.conf we used on Debian Stretch.
I'll clean up our settings in /etc/fail2ban/jail.conf, and, only specify SSHD and Dropbear.
Tests:
@Saxndi
~Fixed in v6.1, you can resolve now (copy paste all):~
Completed.
Config needs further review
Confirms ban action, but has no effect with banaction = route
2018-01-29 15:38:59,748 fail2ban.jail [4779]: INFO Jail 'ssh' started
2018-01-29 15:38:59,757 fail2ban.jail [4779]: INFO Jail 'dropbear' started
2018-01-29 15:38:59,759 fail2ban.jail [4779]: INFO Jail 'sshd' started
2018-01-29 15:39:00,749 fail2ban.actions [4779]: NOTICE [ssh] Ban 192.168.0.27
2018-01-29 15:39:39,820 fail2ban.filter [4779]: INFO [ssh] Found 192.168.0.27
entry should be sshd
๐ฏ๏ธ Removal of failing protocol="%(protocol)s", chain="%(chain)s" in action_
Verified service and openssh-server banning with:
Now I have to wait 10 minutes lol
@Saxndi
Resolved, copy and paste all:
echo 0 > /var/log/auth.log
cat << _EOF_ > /etc/fail2ban/fail2ban.conf
[Definition]
# loglevel #1=error #2=warn #3=info
loglevel = 3
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock
pidfile = /var/run/fail2ban/fail2ban.pid
_EOF_
cat << _EOF_ > /etc/fail2ban/jail.conf
[DEFAULT]
enabled = true
ignoreip = 127.0.0.1/8
ignorecommand =
backend = auto
bantime = 600
findtime = 600
maxretry = 3
banaction = route
action_ = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s"]
action = %(action_)s
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6
[dropbear]
enabled = true
port = ssh
filter = dropbear
logpath = /var/log/auth.log
maxretry = 6
_EOF_
dietpi-services restart
Completed (again) :)
Most helpful comment
@Fourdee
๐ As it seems RPi specific, I can't test it here fast.
Just remembered the old fail2ban issue on Debian Stretch Status issue, and that we did not fix the RPi specific issue there, just the general Stretch issue with non-existent
/var/log/auth.log.One report there lead me to this: https://github.com/Fourdee/DietPi/issues/1428#issuecomment-361235269 Doubled port declaration should not make sense of course.
But sadly doesn't seem to be the (only) issue of Saxndi.