Page 1 of 1
watching an ip get through a CIDR block in CSF 10.25
Posted: 15 Sep 2017, 19:27
by 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
Re: watching an ip get through a CIDR block in CSF 10.25
Posted: 15 Sep 2017, 19:37
by 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
Re: watching an ip get through a CIDR block in CSF 10.25
Posted: 15 Sep 2017, 20:16
by 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)
Re: watching an ip get through a CIDR block in CSF 10.25
Posted: 16 Sep 2017, 11:31
by 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
Re: watching an ip get through a CIDR block in CSF 10.25
Posted: 16 Sep 2017, 11:58
by ForumAdmin
That usually happens if you are using a proxy service such as Cloudflare which will effectively remove the source IP from the OS.
Re: watching an ip get through a CIDR block in CSF 10.25
Posted: 16 Sep 2017, 14:51
by aww+
ForumAdmin wrote: ↑16 Sep 2017, 11:58
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
Re: watching an ip get through a CIDR block in CSF 10.25
Posted: 16 Sep 2017, 15:02
by 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
Re: watching an ip get through a CIDR block in CSF 10.25
Posted: 18 Sep 2017, 15:52
by 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