watching an ip get through a CIDR block in CSF 10.25

[aww+]

so I am currently watching an IP address in the middle of a csf.deny CIDR block access the webserver

newest csf (10.24 upgraded to 10.25, no change)
restarted csf
control panel reports everything is fine

how is this even possible and where do I even begin to diagnose what has gone very wrong?

the max entries allowed for csf.deny is definitely more than what is in there, it's not being truncated

centos 7.1 if it matters

[aww+]

csf --grep x.x.x.x
does show that the ip ends up with a permanent block from csf.deny

yet they are still on the server

Code: Select all

csf --grep 12.34.56.78

Chain            num   pkts bytes target     prot opt in     out     source               destination         

DENYIN           2        0     0 DROP       all  --  !lo    *       12.34.56.78        0.0.0.0/0

DENYOUT          1        0     0 LOGDROPOUT  all  --  *      !lo     0.0.0.0/0            12.34.56.78

IPSET: Set:chain_DENY Match:12.34.56.78 Setting: File:/etc/csf/csf.deny

IPSET: Set:bl_BDE Match:12.34.56.78 Setting:BDE file:/etc/csf/csf.blocklists

IPSET: Set:cc_us Match:12.34.56.78 Setting:CC_ALLOW_PORTS Country:US

ip6tables:

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

Permanent Blocks (csf.deny): 12.34.56.0/19 # Manually denied: 12.34.56.0/19 

note the cc_us match is because there is a hidden port on the server with knocking but they are coming in through the front door via the web server port 80 which clearly should be denied

[aww+]

starting to wonder if this is a security bug/hole with an older nginx version that is allowing IPs to be spoofed because I've been watching netstat and never saw the reported IP appear on the server

will monitor further and report if this is my fault (or not)

[aww+]

okay I've eliminated nginx and php as any possible source of a spoofing problem

bad behavior is back with new IP

and new IP is still punching right though the firewall rule block

this makes zero sense to me how this is happening and why I cannot see that IP in netstat

[ForumAdmin]

That usually happens if you are using a proxy service such as Cloudflare which will effectively remove the source IP from the OS.

[aww+]

That usually happens if you are using a proxy service such as Cloudflare which will effectively remove the source IP from the OS.

no reverse proxies in use but I finally figured this out, I think, still monitoring for results but the logic seems right

I stupidly forgot that using "Include" for external IP lists in csf.deny of course would count against the DENY_IP_LIMIT which makes sense

so while csf.deny only had 500 entries, the include already had nearly 1000

anything at the bottom of csf.deny was probably being ignored because that total is over 1000

still not quite sure why the tempban was being ignored but maybe I was wrong about that

given this experience I'd like to request a feature where CSF or LFD will emit a warning that there are IPs being ignored when it starts up?

I know that there is a warning emitted when DENY_IP_LIMIT is set like over 1000 but there is no counting done for the total IPs listed in csf.deny+includes ?

Additionally, and this might be harder but maybe I need to go back and readup on the IPSET feature, it would be nice to tell CSF to import an include for csf.deny as an IPSET block instead of the conventional deny perm method?

ie. maybe

*csf.deny
Include IPSET attackbots 'attack-bots.txt'

where attackbots is the suggested IPSET block name and it imports that list?

csf might indirectly have this ability now, I admittedly am about six months behind on reading new features

[aww+]

ah okay I see the perm deny does already use IPSET so any includes would go into that block and the ip limit can be raised very high

the temp ban still uses conventional method and 1000 is recommended max

I can live with that, works great

a truncation warning for too many in csf.deny+includes on startup however is probably still a good idea if not difficult to implement?

I need to study LF_IPSET_HASHSIZE and LF_IPSET_MAXELEM to understand how many deny ips is too many

[aww+]

update - you were right, I totally forgot to check but the client had activated caching with cloudflare

we had only been using them for dns but someone switched on the reverse proxy

so cloudflare is stupidly forwarding all requests from their IP and of course we cannot block them

have to look into a solution at the nginx layer to block the CF-Connecting-IP header and/or X-Forwarded-For because I know that is outside the scope of CSF/LFD's layer

btw these are amazing commands to help debug because of nginx's limited logging ability

TCPDUMP for HTTP POST

Code: Select all

tcpdump -s 0 -A 'tcp dst port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)'

or just monitor GET

Code: Select all

tcpdump -s 0 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

they can be passed through grep to filter more

also important for google searches

the Cloudflare plugin for WordPress takes the liberty upon itself to mess with PHP entirely and overwrite the true IP with the forwarded IP address - the code is in IpRewrite.php

at least it checks to make sure the originating IP is a cloudflare server that could be a hell of a security hole

now trying to think of a way to mesh the LFD bans with this messed up process