IP addresses blocked forever after "can't fork"

Kent Brockman · Post by **Kent Brockman** » 28 Oct 2008, 01:42

I've noticed in small boxes that after a lite DOS was occured and the system memory have reached its top value, the lfd hangs, "can't fork" errors are issued, lfd is dead, and the temporarily blocked IP addresses remain blocked in iptables. I've also noticed that that blocks are not cleared nor un-orphaned when you start the csf again. That's cool because, under a DDoS attack, your iptables will be still protecting you even if csf have falled down. BUT, problems may arise when everything returns to normality, because that blocked IP's remain being DROPped in iptables. When I enter the csf.deny editor in my WHM, and save the changes, and after that I restart the CSF, then the iptables will flush that orphan IP's.
I don't know if that it is the pretended behaviour by Chirpy, because after you start csf, or chkservd start it, CSF seems to lose track of what IP's have been blocking, and that's why it doesn't flush'em as usually would do it when you restart it. I think this is a behaviour annoyance based in some scenario created when the lfd process is killed: it loses track of what has been doing.

And the problem with this behaviour is.... that until you don't put an eye on your iptables DROP section, you won't realize that it may be very loaded of IP addresses orphaned by a killed instance of lfd, and after I've tracerouted all them I found that 90% are dynamic IP's from normal ISP's, and the DDoS is coming from zombie machines, so the temporary block may be cleaned out without endangering your box. This is a problem because lfd won't clear that IP's until you save changes to csf.deny/allow files and restart the program, making possible that a sustained DDoS consume as many resources to hang lfd, generating lots of blocked IP's that won't be flushed when the firewall is started again, consuming the resources of your iptables and making a DDoS in itself. That's what I've seen after big DDoS's.

It would be great that when lfd starts, it checks what is in the DROP lists and show these IP's in the "temporary IP ban" list, so you can decide what do you want to do with all that mess of blocks, or at less, lfd resumes the temporary block assigning a new countdown time from that moment to know when to free those IP's.
Also, and I think this would improve the usability of csf, the amount of temporarily blocked IP's should be visible at the top of the window, sustracting in that way some clicks to scroll down the page, and it would be useful to take a quick look and focusing in what is happening right now without looking at anywhere else.

I hope not to be very pretentious, and I hope to not have misunderstood the behaviour of lfd in such cases, but after have been attacked several times, I can say from experience that these are good suggestions to improve the tasks of lfd.
Thank you for the best software firewall, chirpy, I love it.

Post by **chirpy** » 31 Oct 2008, 15:35

lfd and csf already do track temporary IP addresses between runs. What probably happened is that lfd was killed while it was writing to the file that controls that (csf.tempban) and it resulted in an empty file. That's really an issue for the OS and the VPS since it would be unlikely to happen on a real server.

That said, I will be moving csf.tempban over to a tied array file which should prove more stable. To recover from this type of situation and simple restart of csf is all that is needed.

Kent Brockman · Post by **Kent Brockman** » 31 Oct 2008, 19:35

Cool. I just have upgraded to v4.18 .
I'll watch it these next days and see if this solve the issue.
Thank you!!

Kent Brockman · Post by **Kent Brockman** » 01 Nov 2008, 22:28

chirpy wrote:lfd and csf already do track temporary IP addresses between runs. What probably happened is that lfd was killed while it was writing to the file that controls that (csf.tempban) and it resulted in an empty file. That's really an issue for the OS and the VPS since it would be unlikely to happen on a real server.

That said, I will be moving csf.tempban over to a tied array file which should prove more stable. To recover from this type of situation and simple restart of csf is all that is needed.

The 4.18 version worked great, being able to handle the blocked IP's after lfd was killed. The new v4.19 have rolled back everything to the annoyance of preceding versions.

I'm on a VPS and lfd uses to hang sometimes...

Will this have any workaround? I suppose not to be the only with this problems.

Regards