csf -dr glitch

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.
3 posts Page 1 of 1
loqub
Junior Member
Posts: 1
Joined: 08 Jul 2016, 00:02


This is actually in reference to another bug that was recently fixed.

9.07 - Fixed removal of complex allow and deny rules

viewtopic.php?f=4&t=9603

It appears that these changes are preventing complex rules from being removed when using the IP address itself. This complicates things when iptables rules generated for LFD automated blocks are entered. As an example:
Code: Select all
tcp|in|d=2078|s=1.2.3.4 # lfd: (cpanel) Failed cPanel login from 1.2.3.4 (PA/Panama/-): 5 in the last 3600 secs - Wed Jun 29 16:08:07 2016
tcp|in|d=2082|s=1.2.3.4 # lfd: (cpanel) Failed cPanel login from 1.2.3.4 (PA/Panama/-): 5 in the last 3600 secs - Wed Jun 29 16:08:07 2016
tcp|in|d=2083|s=1.2.3.4 # lfd: (cpanel) Failed cPanel login from 1.2.3.4 (PA/Panama/-): 5 in the last 3600 secs - Wed Jun 29 16:08:08 2016
tcp|in|d=2086|s=1.2.3.4 # lfd: (cpanel) Failed cPanel login from 1.2.3.4 (PA/Panama/-): 5 in the last 3600 secs - Wed Jun 29 16:08:08 2016
tcp|in|d=2087|s=1.2.3.4 # lfd: (cpanel) Failed cPanel login from 1.2.3.4 (PA/Panama/-): 5 in the last 3600 secs - Wed Jun 29 16:08:09 2016
tcp|in|d=2095|s=1.2.3.4 # lfd: (cpanel) Failed cPanel login from 1.2.3.4 (PA/Panama/-): 5 in the last 3600 secs - Wed Jun 29 16:08:09 2016
tcp|in|d=2096|s=1.2.3.4 # lfd: (cpanel) Failed cPanel login from 1.2.3.4 (PA/Panama/-): 5 in the last 3600 secs - Wed Jun 29 16:08:09 2016
These blocks will not remove with csf -dr 1.2.3.4 anymore.
Code: Select all
csf -dr 1.2.3.4
csf: 1.2.3.4 not found in csf.deny
They are visible with csf -g:
Code: Select all
csf -g 1.2.3.4

Chain            num   pkts bytes target     prot opt in     out     source               destination         

DENYIN           91       0     0 DROP       tcp  --  !lo    *       1.2.3.4              0.0.0.0/0           tcp dpt:2078
DENYIN           92       0     0 DROP       tcp  --  !lo    *       1.2.3.4              0.0.0.0/0           tcp dpt:2082
DENYIN           93       0     0 DROP       tcp  --  !lo    *       1.2.3.4              0.0.0.0/0           tcp dpt:2083
DENYIN           94       0     0 DROP       tcp  --  !lo    *       1.2.3.4              0.0.0.0/0           tcp dpt:2086
DENYIN           95       0     0 DROP       tcp  --  !lo    *       1.2.3.4              0.0.0.0/0           tcp dpt:2087
DENYIN           96       0     0 DROP       tcp  --  !lo    *       1.2.3.4              0.0.0.0/0           tcp dpt:2095
DENYIN           97       0     0 DROP       tcp  --  !lo    *       1.2.3.4              0.0.0.0/0           tcp dpt:2096


ip6tables:

Chain            num   pkts bytes target     prot opt in     out     source               destination         
No matches found for 1.2.3.4 in ip6tables

They will remove if they are entered fully with csf -dr 'tcp|in|d=2096|s=1.2.3.4'
Code: Select all
csf -dr 'tcp|in|d=2096|s=1.2.3.4'
Removing rule...
DROP  tcp opt -- in !lo out *  1.2.3.4  -> 0.0.0.0/0  tcp dpt:2096 

With several of these type of blocks, there are several ports locked from a single LFD entry. In prior releases, a single -dr would remove all of these. Considering complex rules were not removable in this method only days ago, it seems to be related. If this is intended, it would be helpful to put an additional flag for a deeper remove that will kill any matches on deny chain with the IP address itself.
ForumAdmin
Moderator
Posts: 1450
Joined: 01 Oct 2008, 09:24


Thank you for reporting this. We'll look into getting a fix out soon.
ForumAdmin
Moderator
Posts: 1450
Joined: 01 Oct 2008, 09:24


This should now be fixed in v9.10 which we have just released:
http://blog.configserver.com/
3 posts Page 1 of 1