ConfigServer Community Forum

Has this issue ever been properly fixed? It looks like we are having the same issue with csf: v14.22 and a Spain IP address 81.32.94.235: When I check the CSVs GeoLite2-Country-Blocks-IPv4.csv:81.32.0.0/12,2510769,2510769,,0,0, GeoLite2-Country-Locations-en.csv:2510769,en,EU,Europe,ES,Spain,1 Yet ru...

Just a follow up that CT_LIMIT is still blocking the servers own IP address. This was from an AlmaLinux 9 server running csf: v14.19 (generic): Sep 3 04:25:48 www0 lfd[2282494]: (CT) IP 158.69.XXX.XXX (CA/Canada/www0.example.com) found to have 858 connections - *Blocked in csf* for 1800 secs [CT_LIM...

MaxMind will require https:// for all database downloads. Currently CSF uses unsecure http:// in Config.pm Email sent from MaxMind: Dear MaxMind customer, We’re writing because, between July 15 and August 14, we saw GeoIP download requests from your account that are not being sent with HTTPS (see de...

Unfortunately this isn't fixed like the CSF 14.19 changelog says. I've confirmed this on Almalinux and CloudLinux: # csf --version csf: v14.19 (generic) When I delete the `/home/csf/public_html/` directory and restart the login failure daemon everything gets re-created but the .htaccess is missing t...

This is what works well for us. You have to tell the slaves to send to one another so the cluster config is the same across all of the slaves: MASTER: 192.168.1.2 SLAVE1: 192.168.1.3 SLAVE2: 192.168.1.4 CLUSTER_SEND_TO: 192.168.1.3,192.168.1.4 CLUSTER_RECEIVE_FROM: 192.168.1.2,192.168.1.3,192.168.1....

Just a note that this was unfortunately not fixed in CSF v14.19.

Something changed in the latest on AlmaLinux 8.8 and 9.2 so the messenger v3 service wasn't working when you accessed it: [Mon Jul 17 04:18:06.481590 2023] [authz_core:error] [pid 1561524:tid 140582131332864] [client 207.194.202.202:62109] AH01630: client denied by server configuration: /home/csf/pu...

Regex patterns are stored in /usr/local/csf/lib/ConfigServer/RegexMain.pm. It's pretty easy to do some failed logins then test the regex using the matching pattern in that file. Then you can use a website like https://regex101.com/ to see if the pattern works. Can you post some sample failed logins ...

My guess is that it might be related to this then: Users may change to journalctl or use the new "high precision timestamps" that rsyslog now uses. If the timestamp format has changed then the regex that CSF uses would have to account for that. Unfortunately that also means that you would ...

Most OS are switching to using journald instead of rsyslog. If you look at the Debian 12 announcement you will see this: https://www.debian.org/News/2023/20230610 Quote: There are some changes to system logging; the rsyslog package is no longer needed on most systems, and is not installed by default...