Log File Flooding Variable
Posted: 25 Jul 2024, 05:27
Greetings, within /etc/csf/lfd.pl, we have this little tidbit of code within the getlogfile section (between lines 2194 to 2248).
Would it be possible to do the following in a future release:
1) Reconfigure the `1000` to a settable integer within csf.conf's LFD section? 1000 being the csf.conf default.
2) If the variable is empty or set to 0, the entire check will by bypassed. A warning would then be broadcast when the input is set above 5000.
As it stands right now, I've manually edited this to 10000 to workaround the log file flooding issue - simply so that CSF can still see the slip/block notices. I've had a couple instances now where some servers end up with log file flooding due to albeit, significant, DNS Reflection Amplification attacks. While BIND9 is doing its job to slip (response truncation) then halt (limit drop) responses with the problem IP's (they're spoofed since its UDP, but halting the traffic is best overall), it is more often than not missing the block notices sent by BIND9.
Code: Select all
if ($totlines > ($config{LF_PARSE} * 1000)) {
my $text = "*Error* Log line flooding/looping in $logfile. Reopening log file";
logfile("$text");
if ($config{LOGFLOOD_ALERT}) {
my @alert = slurp("/usr/local/csf/tpl/logfloodalert.txt");
my @message;
foreach my $line (@alert) {
$line =~ s/\[text\]/$text/ig;
push @message, $line;
}
ConfigServer::Sendmail::relay("", "", @message);
}
if (&openlogfile($logfile,$lfn)) {return undef}
return "reopen";
}
1) Reconfigure the `1000` to a settable integer within csf.conf's LFD section? 1000 being the csf.conf default.
2) If the variable is empty or set to 0, the entire check will by bypassed. A warning would then be broadcast when the input is set above 5000.
As it stands right now, I've manually edited this to 10000 to workaround the log file flooding issue - simply so that CSF can still see the slip/block notices. I've had a couple instances now where some servers end up with log file flooding due to albeit, significant, DNS Reflection Amplification attacks. While BIND9 is doing its job to slip (response truncation) then halt (limit drop) responses with the problem IP's (they're spoofed since its UDP, but halting the traffic is best overall), it is more often than not missing the block notices sent by BIND9.