Just installed CSF firewall on another server but am getting some IPs blocked for some reason, though their not listed in csf-deny ??? Any ideas ?
You'll get those when you first install and start csf. They happen because iptables doesn't know about existing connections yet (it hasn't populated the connection tracking tables) and only allows NEW connections out, so they get blocked. It'll sort itself out.
OK, thanks for the info.
Off topic .......
And congrats to your company
I see that CSF is now also available to those that have WHMXtra installed.
Well done !!
Off topic .......
And congrats to your company
I see that CSF is now also available to those that have WHMXtra installed.Well done !!
Last edited:
Chirpy,
I've got an identical problem, but I have just found an IP that has been blocked for a good 5 days now. How long does this take to sort out, and is there a way to manually flush this thing?
Thanks much.
Yipes! This is starting to look like an extremely searious issue for the scf firewall, which is otherwise a great security package.
I would hate to go back to APF/BFD but we need to be able to trust that the firewall is not haphazardly blocking legitimate IPs.
I'm looking for a way to manually flush the said connection table. Here's the errant behavior we are noticing:
-- IP is blocked, and is not in the csf.deny file, nore does it come up with iptables --list
-- I put the IP in the csf.allow file and it is then unblocked (after restarting csf).
-- I restart iptables flushing out all the old rules (also restart csf at this point).
-- I remove the formerly blocked IP from the csf.allow file and restart cdf.
-- The IP is once again blocked!!!
This seems to be a kernel level block as iptables seems to be bypassed in this kind of situation, but I can't find where the kernel is picking up the old IP address for the block. Anyone?
I would hate to go back to APF/BFD but we need to be able to trust that the firewall is not haphazardly blocking legitimate IPs.
I'm looking for a way to manually flush the said connection table. Here's the errant behavior we are noticing:
-- IP is blocked, and is not in the csf.deny file, nore does it come up with iptables --list
-- I put the IP in the csf.allow file and it is then unblocked (after restarting csf).
-- I restart iptables flushing out all the old rules (also restart csf at this point).
-- I remove the formerly blocked IP from the csf.allow file and restart cdf.
-- The IP is once again blocked!!!
This seems to be a kernel level block as iptables seems to be bypassed in this kind of situation, but I can't find where the kernel is picking up the old IP address for the block. Anyone?
might wanna check the logs to see WHY the ips get blocked. if the ip is a legit one and for example gets blocked because of too many wrong password auth, then you should add it to the whitelist, and LEAVE IT THERE, otherwise it will get blocked again.
im using chirpy's csf and it totally rocks. you need to check logs good though ... and to see which are legit and add them to whitelist.
im using chirpy's csf and it totally rocks. you need to check logs good though ... and to see which are legit and add them to whitelist.
From the information you gave me off-forum there doesn't appear to be any problem at all. Someone is trying to connect out from the server over UDP using a port that isn't open in the firewall, so it is quite correctly being blocked by iptables.
Even if it is a firewall issue, it's nothing to do with csf whatsoever - it's down to iptables.
Here's a sample from ports that need to be open:
Nov 29 04:47:33 host kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=myserver DST=61.5.4.241 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=7176 DF PROTO=TCP SPT=80 DPT=3278 WINDOW=6432 RES=0x00 ACK PSH URGP=0
Nov 29 04:50:43 host kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=myserver DST=84.165.249.79 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=3085 DF PROTO=TCP SPT=25 DPT=64423 WINDOW=5840 RES=0x00 ACK PSH URGP=0
Nov 29 04:47:33 host kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=myserver DST=61.5.4.241 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=7176 DF PROTO=TCP SPT=80 DPT=3278 WINDOW=6432 RES=0x00 ACK PSH URGP=0
Nov 29 04:50:43 host kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=myserver DST=84.165.249.79 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=3085 DF PROTO=TCP SPT=25 DPT=64423 WINDOW=5840 RES=0x00 ACK PSH URGP=0
Sorry for the confusion, that's just me trying to do a traceroute on the blocked IP, as a test.
The issue persists. I agree that it may not have anything to do with csf, but why in the heck would an IP be blocked no matter what? Even if it does not show up when doing iptables --list ???? Why would the kernel be denying access for this IP?
Well it must have, we never got this problem before in the hourly email, and they all start off with:
Date xx host kernel: Firewall: *TCP_OUT Blocked ..... bla bla bla.
Okay UPDATE - I uninstalled CSF on one of our servers that had this problem, then reinstalled APF and BFD and now the issue is apparently resolved.
This was a very strange issue, to recap, we found that an unknown number of legitimate IPs were being blocked even though the IPs (that we discovered were blocked) were NOT in the csf.deny file, and were not even listed in iptables --list
BUT, I could de-block the IP by inserting it in the csf.allow file then restarting csf.
Because we have absolutely no way of knowing which IPs were blocked, we are now having to uninstall CSF everywhere and are going back to APF/BFD.
I hope Chirpy get's this very critical issue resolved soon, because to otherwise CSF kicks ass. Currently however, the way all this looks, it is useless. Sad to say.
This was a very strange issue, to recap, we found that an unknown number of legitimate IPs were being blocked even though the IPs (that we discovered were blocked) were NOT in the csf.deny file, and were not even listed in iptables --list
BUT, I could de-block the IP by inserting it in the csf.allow file then restarting csf.
Because we have absolutely no way of knowing which IPs were blocked, we are now having to uninstall CSF everywhere and are going back to APF/BFD.
I hope Chirpy get's this very critical issue resolved soon, because to otherwise CSF kicks ass. Currently however, the way all this looks, it is useless. Sad to say.
i disagree with that last statement , as all the IPs which are blocked on our server by CSF are dodgey ones from china , taiwan and russia.
go and do a whois search and see what is being blocked http://www.whois.sc/
maybe it has got something to do with the additional features of
http://feeds.dshield.org/block.txt
and http://www.spamhaus.org/drop/drop.lasso , which is a great addon !
go and do a whois search and see what is being blocked http://www.whois.sc/
maybe it has got something to do with the additional features of
http://feeds.dshield.org/block.txt
and http://www.spamhaus.org/drop/drop.lasso , which is a great addon !
I tested this by switching off both dshield (which is also in APF by the way) and spamcop. This was not the cause of the issue.
The IPs that we found that were seemingly randomly blocked were not "dodgy" as you say, not from China or Tiwan, more like from the US, UK and Canada.
Here are some whois lookups of the very last IP that was seemingly haphazardly blocked:
http://www.dnsstuff.com/tools/whois.ch?ip=71.222.35.228
http://whois.domaintools.com/71.222.35.228
And to emphasize, the blocked IPs were NOT found in the csf.deny list, nor were they even listed in iptables --list. HOWEVER the block was seemingly removed upon adding the blocked IP to csf.allow (and then restarting csf or course) AND the block was removed by completely un-installing csf and replacing this with apf.
Now I am trying to figure out how to get back some capability that we really like that was in CSF, like the ability to send us an alert and even "lock" a script that in someone's account that has broadcasted too many email messages. And the ability to send an alert when a suspicious file is found in /tmp.
Bottom line, I am hoping that Chirpy get's this flaw resolved soon in CSF.
The IPs that we found that were seemingly randomly blocked were not "dodgy" as you say, not from China or Tiwan, more like from the US, UK and Canada.
Here are some whois lookups of the very last IP that was seemingly haphazardly blocked:
http://www.dnsstuff.com/tools/whois.ch?ip=71.222.35.228
http://whois.domaintools.com/71.222.35.228
And to emphasize, the blocked IPs were NOT found in the csf.deny list, nor were they even listed in iptables --list. HOWEVER the block was seemingly removed upon adding the blocked IP to csf.allow (and then restarting csf or course) AND the block was removed by completely un-installing csf and replacing this with apf.
Now I am trying to figure out how to get back some capability that we really like that was in CSF, like the ability to send us an alert and even "lock" a script that in someone's account that has broadcasted too many email messages. And the ability to send an alert when a suspicious file is found in /tmp.
Bottom line, I am hoping that Chirpy get's this flaw resolved soon in CSF.
One problem can occur with the dropping of bad TCP packets. I've released a new version of csf that can better log invalid and out of sequence TCP packets that could be the cause that these few people see. If you enable DROP_PF_LOGGING and believe you then see excessive INV_* and/or INVALID packet drops in /var/log/mesages then you likely either have a buggy iptables/kernel relationship on your server, or a client whose PC is dropping essential TCP traffic packets, and should disable the PACKET_FILTER option in csf.
This probably wouldn't be apparent in APF as it isn't as rigourous at configuring iptables in weeding out invalid and out of sequence tcp packets.
This probably wouldn't be apparent in APF as it isn't as rigourous at configuring iptables in weeding out invalid and out of sequence tcp packets.
Last edited:
Chirpy, you closed our support ticket we had open at configservers about this, so the forum is the only way to continue hoping for a resolution here. I wish you would have at least taken a look at the precice example on our server that we had given. Knowing a little about your skills you probably would have smoked this one out right away.
I know that CSF is basicaly a free and unsupported package. But mainly I just wanted to help you get this thing up to gold standards if there were a serious issue with it, and apparently there is.
------------------------------------
I tried your suggestion in the most recent post but it's a "no go".
-- I upgraded CSF to the newest version.
-- For one of the IPs that were being errantly blocked, I did the following:
-- I removed the IP from the csf.allow file and restarted csf.
-- I checked the csf deny file just to make sure that this same IP address is not listed there. (It's not).
-- I checked iptables --list to make sure that this IP is not listed there (It's not, neither is the subnet of this particular IP.)
-- After restarting csf, I tested using the traceroute command for that IP at the shell to verify that the IP has been re-blocked at this point (It is.)
-- I disable the PACKET_FILTER option in csf, and restarted csf. The IP is STILL blocked.
No resolution in site? No way to tell how many other IPs are being blocked? If true, the for us there is no other choice than to un-install CSF and go back to APF/BFD. I dearly wish there were another route to take here.
I know that CSF is basicaly a free and unsupported package. But mainly I just wanted to help you get this thing up to gold standards if there were a serious issue with it, and apparently there is.
------------------------------------
I tried your suggestion in the most recent post but it's a "no go".
-- I upgraded CSF to the newest version.
-- For one of the IPs that were being errantly blocked, I did the following:
-- I removed the IP from the csf.allow file and restarted csf.
-- I checked the csf deny file just to make sure that this same IP address is not listed there. (It's not).
-- I checked iptables --list to make sure that this IP is not listed there (It's not, neither is the subnet of this particular IP.)
-- After restarting csf, I tested using the traceroute command for that IP at the shell to verify that the IP has been re-blocked at this point (It is.)
-- I disable the PACKET_FILTER option in csf, and restarted csf. The IP is STILL blocked.
No resolution in site? No way to tell how many other IPs are being blocked? If true, the for us there is no other choice than to un-install CSF and go back to APF/BFD. I dearly wish there were another route to take here.
By the way, I don't need to completely uninstal csf to get the IP in question un-blocked. Just stoping csf via "service csf stop" instantly unblocked this IP, again, eventhough this IP is NOT in the csf.deny file.
I wish you would have been able to offer one tiny bit more support for this one. We've hired you several times in the past and your work has always been flawless.
I am going to uninstall CSF from our servers now, but if you would like to use the server and IP and question for a test, please just let us know. I would much prefer to use CSF than APF we could only get it up to a trustworthy level.
Thanks anyway.
I wish you would have been able to offer one tiny bit more support for this one. We've hired you several times in the past and your work has always been flawless.
I am going to uninstall CSF from our servers now, but if you would like to use the server and IP and question for a test, please just let us know. I would much prefer to use CSF than APF we could only get it up to a trustworthy level.
Thanks anyway.
/me subscribes to this thread - looking to see if this is buggy iptables or stringent rules need to be eased
At this stage, I would asume buggy iptables as csf is now running on thousands of servers and I've only had these two reports of any problems with the rules in this manner. It's never going to suite everyone, and if it doesn't work for you, then using an alternative is always going to be a good idea, it would be easy to dial back the rules and make them less stringent, but that would make it less secure for everyone and defeat the main purpose of an SPI firewall.
We did this on three different Linux OS and all it did was increase the the amount of banned IPs in the hourly email report Why does stuff like the entry's below get blocked?
Dec 3 11:19:01 host kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=our-server DST=81.248.142.85 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=41083 DF PROTO=TCP SPT=80 DPT=1645 WINDOW=5840 RES=0x00 ACK FIN URGP=0
Dec 3 09:15:44 host kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:14:85:e2:e0:7b:00:d0:03:33:84:00:08:00 SRC=192.168.1.5 DST=our-server LEN=40 TOS=0x00 PREC=0x00 TTL=108 ID=12960 DF PROTO=TCP SPT=1271 DPT=80 WINDOW=24615 RES=0x00 ACK FIN URGP=0
| Thread starter | Similar threads | Forum | Replies | Date |
|---|---|---|---|---|
| D | You must stop and disable firewalld when using csf | Security | 2 | |
| Y | CSF Firewall recommendations | Security | 1 | |
| N | CSF Firewall Missing 2 Module (insmod) | Security | 20 | |
|
APF to CSF Firewall | Security | 3 | |
| V | SMTP erorro after enabling ConfigServer Security & Firewall(CSF) in WHM Panel. | Security | 7 |