IP addresses blocked forever after "can't fork"
Posted: 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.
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.
