This forum is only for reproducible bugs with csf and lfd (i.e. not iptables problems, lack of understanding how to use a feature, etc). Posts must be accompanied with full technical details of the problem and how it can be recreated. Any posts not adhering to this, or not considered bugs, will be moved to the General Discussion (csf) forum.
Tried testing the CSF 4.06 for the temp and perm blocking giving the block message. In the TEMP port 21 will direct to the message, but for PERM it will not. Here are my files
I first noticed these two issues after an auto-upgrade to 4.02, and they persist in 4.04.
1. Global allow rules not being updated
I have a GLOBAL_ALLOW url specified in my configuration file. Upon CSF/LFD initialization (or manual restart), these rules are applied correctly:
Chain GALLOW (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT tcp -- eth+ *...
Seems like Bogon is active on eth1 even though I excluded it from firewall rules in:
ETH_DEVICE_SKIP = eth1
I run internal network using 192.168.0.x to connect to internal NAS server.
Looks like the newest csf update causes this to break. It was fine in earlier versions. I had the server set to autoupdate csf and found out this morning that it had issues connecting to NAS (it wouldn't...
I am experiencing an issue with v4.02 after an intended automatic upgrade early this morning; it seems that our custom port range specified for TeamSpeak voice service over UDP is being blocked for inbound and outbound traffic.
Here are two of many syslog entries indicating the blocks (munged): Sep 9 12:38:30 servername kernel: Firewall: *UDP_IN Blocked* IN=eth1 OUT=...
With v3.43 of CSF I have been seeing that an IP address may not always be removed from iptables/csf after the temporary time span has elapsed. The IP address is blocked for triggering LFD from failed logins; here is a more descriptive log report from LFD:
(I''ve replaced the last octet with an X.)
# grep -i 72.226.154.X /var/log/lfd.log
Tue Sep 2 21:42:18 2008 lfd: Failed cPanel login...
I noticed that 67.210.XXX.XXX has been constantly getting blocked because of port scans so I made a permanent block with 67.210.0.0/16
The problem is that even though it's permanently blocked, csf will still detect port scans and block any IP within the permanently blocked range. It will also then permanently block the IP after after X number attempts even though the c-block is already...
I have noticed that when a cdir address (eg.67.210.3.1/24) is blocked in the csf deny list, continued hammering by ips within that subnet still trigger the csf temp ban emails. (eg. 67.210.3.66, and 67.210.3.69 will trigger temp bans if hammering even after subnet is denied.)
this could give an attacker a way to flush out the temp ban list even if the flushing subnet has benn permanentely...
I dont know if this was fixed in the very last release but I know the one before it had this problem. Basicaly if you had connection tracking on tmp ban it would ban whitelisted ips. For example I had a few server setups that use remote sql and such and everyone I had set on tmp ban was banning the mysql server. I am positive the ips were whitelisted in all instances.
Premature end of script headers: /usr/local/cpanel/whostmgr/docroot/cgi/addon_csf.cgi: Please check /usr/local/cpanel/logs/error_log for the exact error.
this is occuring in all our servers running WHM C25133
A couple of versions ago, something changed with the way that CSF treats hostnames listed in the lfd Dynamic DNS .
I am now receiving email alerts of the form lfd: SSH login alert for user XXXXX from AAA.BBB.CCC.DDD (Unknown)
each time I login to the server from this IP addresss, which one of the hostnames listed in the lfd Dynamic DNS list resolves to.
Working with cPanel, they seem to locate an issue with CSF/LFD that is causing the packaging of a full backup to end prematurely from cpanel, but yet the the file is sent to the remote destination.
The package restores fine, but again, not everything is restored.
After much testing, I have been able to replicate
the issue with the test1 account and a test account, using 2 different ftp
hosts....
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum