ClearOS Bug Tracker


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0017131ClearOSapp-attack-detector - Attack Detectorpublic2017-09-14 14:412017-09-21 19:54
ReporterNickH 
Assigned Touser2 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version7.4.0 Beta 1Fixed in Version7.4.0 Beta 1 
Summary0017131: Race condition in app-attack-detector on boot
DescriptionPlease see the forum thread https://www.clearos.com/clearfoundation/social/community/attack-detector-fail2ban-sshd-iptables-rule-missing-at-boot-time# [^]

On boot up, ip_set is not loaded by default so fail2ban loads it at some point when it starts. Unfortunately it appears that f2b starts applying firewall rules before ip_set loads and one of the rules fail.

I've tested with all 5 ClearOS rules enabled on my G10 Microserver and each time I see the following in the logs:

2017-09-14 21:10:39,450 fail2ban.jail [3589]: INFO Jail 'sshd' started
2017-09-14 21:10:39,459 fail2ban.jail [3589]: INFO Jail 'sshd-ddos' started
2017-09-14 21:10:39,462 fail2ban.filtersystemd [3589]: NOTICE Jail started without 'journalmatch' set. Jail regexs will be checked against all journal entries, which is not advised for performance reasons.
2017-09-14 21:10:39,468 fail2ban.jail [3589]: INFO Jail 'proftpd' started
2017-09-14 21:10:39,487 fail2ban.jail [3589]: INFO Jail 'postfix-sasl' started
2017-09-14 21:10:39,498 fail2ban.filtersystemd [3589]: NOTICE Jail started without 'journalmatch' set. Jail regexs will be checked against all journal entries, which is not advised for performance reasons.
2017-09-14 21:10:39,508 fail2ban.jail [3589]: INFO Jail 'cyrus-imap' started
2017-09-14 21:10:39,557 fail2ban.action [3589]: ERROR ipset create f2b-sshd hash:ip timeout 600
iptables -w -I INPUT -m set --match-set f2b-sshd src -j REJECT --reject-with icmp-port-unreachable -- stdout: ''
2017-09-14 21:10:39,558 fail2ban.action [3589]: ERROR ipset create f2b-sshd hash:ip timeout 600
iptables -w -I INPUT -m set --match-set f2b-sshd src -j REJECT --reject-with icmp-port-unreachable -- stderr: "ipset v6.19: Cannot open session to kernel.\niptables v1.4.21: Set f2b-sshd doesn't exist.\n\nTry `iptables -h' or 'iptables --help' for more information.\n"
2017-09-14 21:10:39,563 fail2ban.action [3589]: ERROR ipset create f2b-sshd hash:ip timeout 600
iptables -w -I INPUT -m set --match-set f2b-sshd src -j REJECT --reject-with icmp-port-unreachable -- returned 2
2017-09-14 21:10:39,564 fail2ban.actions [3589]: ERROR Failed to start jail 'sshd' action 'iptables-ipset-proto6-allports': Error starting action

This is really an upstream bug and I'll report it to the f2b mailing list but it can be fixed simply in ClearOS by forcing ip_set to load earlier on boot. To do this we need to drop a file called anything.modules into /etc/sysconfig/modules and give it execute permissions. In it put:
modprobe ip_set

or, if you are more polite, something like:
if [ "`lsmod | grep ip_set`" = "" ]; then
    modprobe ip_set
fi

This could be packaged into app-attack-detector.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0006481)
user2
2017-09-14 19:14

Many thanks for the bug report!

It looks like this was fixed in the 7.4.0 beta (currently in updates-testing). The firewall now loads ip_set on start/boot:

https://github.com/clearos/app-firewall/commit/9fb5fe0d6fe7d22afc22eefd51c3151b64f4fe9b [^]

The firewall systemd configuration (/usr/lib/systemd/system/firewall.service) has this entry:

   Before=fail2ban.service

So in principle, everything should be working in the 7.4.0 beta.

- Issue History
Date Modified Username Field Change
2017-09-14 14:41 NickH New Issue
2017-09-14 19:09 user2 Status new => confirmed
2017-09-14 19:14 user2 Note Added: 0006481
2017-09-14 19:15 user2 Target Version => 7.4.0 Beta 1
2017-09-17 14:35 user2 Status confirmed => resolved
2017-09-17 14:35 user2 Fixed in Version => 7.4.0 Beta 1
2017-09-17 14:35 user2 Resolution open => fixed
2017-09-17 14:35 user2 Assigned To => user2
2017-09-21 19:54 user2 Status resolved => closed