Hello,
first of all, thank you for this great software.
I am running csf+lfd in production environment and I am overall very happy with it. It is easy to manage while powerful enough to supposedly do what I need.
I installed it to prevent SYN_RECV floooding at first, and it does the job.
But with the public release of slowloris, I see an increase in attempts to DoS my sites.
I decided to add the state ESTABLISHED to the CT_STATES value (previously just SYN_RECV) and have a friend test slowloris on me.
On 2 of my servers, I see the block in lfd.log less than a minute after the start of the attack, but on my third one, it does not seem to trigger, at all.
the process is sleeping, I see it block IPs from time to time, but no matter what, it won't see/block my friend, at least not in the delay that i ask it to. And considering apache dies in like 3 minutes max, I need it to trigger fast.
I am sure that the threshold is reached by running:
netstat -an | grep ESTABLISHED | grep xxx.yyy.zzz.aaa | wc -l
I see the number growing until it takes up all the slots and apache dies.
The 3 servers are running 4.75, debian lenny 5.0.2, they are quasi-identical (only CPU and RAM change). Ironically the one that fails is the big one, with 8 CPUs and 8 GBs of RAM.
Is there anything I could look into, in order to see why it fails to trigger?
-pill
lfd daemon does not seem to do Connection Tracking at CT_LIMIT specified interval
-
- Moderator
- Posts: 1524
- Joined: 01 Oct 2008, 09:24
If you replace /etc/csf/lfd.pl with the attached script and then in /etc/csf/csf.conf set:
DEBUG = "4"
Then restart lfd just before you try the test, then lfd will log a great deal of information about what it is doing, including CT debug code. If a CT debug line ends in "count:[N]" then the previous logged line is counted toward CT_LIMIT, otherwise the connection was disgarded. You may have to wade through quite a lot of information in the log.
When you've finished testing, set DEBUG back to 0 and restart lfd.
DEBUG = "4"
Then restart lfd just before you try the test, then lfd will log a great deal of information about what it is doing, including CT debug code. If a CT debug line ends in "count:[N]" then the previous logged line is counted toward CT_LIMIT, otherwise the connection was disgarded. You may have to wade through quite a lot of information in the log.
When you've finished testing, set DEBUG back to 0 and restart lfd.
Same issue here. LFD does trigger but seems to be thinking that the IPs are already blocked - which they are not :
Jul 29 01:45:49 host lfd[7255]: debug: (CT) IP 88.2.194.140 found to have 112 connections - IP already blocked
Jul 29 01:45:49 host lfd[7255]: debug: (CT) IP 68.119.58.248 found to have 123 connections - IP already blocked
Jul 29 01:45:49 host lfd[7255]: debug: (CT) IP 189.162.215.82 found to have 218 connections - IP already blocked
[01:45:48] root@host [~/csf]# csf -g 88.2.194.140
Chain num pkts bytes target prot opt in out source destination
No matches found for 88.2.194.140 in iptables
[01:46:25] root@host [~/csf]# csf -g 68.119.58.248
Chain num pkts bytes target prot opt in out source destination
No matches found for 68.119.58.248 in iptables
[01:47:05] root@host [~/csf]# csf -g 189.162.215.82
Chain num pkts bytes target prot opt in out source destination
No matches found for 189.162.215.82 in iptables
Any idea ?
Thank you
Jul 29 01:45:49 host lfd[7255]: debug: (CT) IP 88.2.194.140 found to have 112 connections - IP already blocked
Jul 29 01:45:49 host lfd[7255]: debug: (CT) IP 68.119.58.248 found to have 123 connections - IP already blocked
Jul 29 01:45:49 host lfd[7255]: debug: (CT) IP 189.162.215.82 found to have 218 connections - IP already blocked
[01:45:48] root@host [~/csf]# csf -g 88.2.194.140
Chain num pkts bytes target prot opt in out source destination
No matches found for 88.2.194.140 in iptables
[01:46:25] root@host [~/csf]# csf -g 68.119.58.248
Chain num pkts bytes target prot opt in out source destination
No matches found for 68.119.58.248 in iptables
[01:47:05] root@host [~/csf]# csf -g 189.162.215.82
Chain num pkts bytes target prot opt in out source destination
No matches found for 189.162.215.82 in iptables
Any idea ?
Thank you