CSF process "/usr/bin/perl /usr/sbin/csf -dr [IP.add.re.ss]" uses a lot of CPU

PeterTouw

PeterTouw

Verified User
Joined
Jun 4, 2020
Messages
7
Location
The Netherlands, Amsterdam
process "/usr/bin/perl /usr/sbin/csf -dr [IP.add.re.ss]" uses a lot of CPU

csf -dr [IP.add.re.ss] Unblock an IP and remove from /etc/csf/csf.deny

A year ago I added a lot of IP addresses to csf.deny because I wanted to block these permanently.
So I inserted these into csf.deny.
Entry examples:
123.123.123.123 # do not delete
124.124.124.124 # do not delete
etc.

Got this info from:
How can I permanently block IP?
forums.cpanel.net

How can I permanently block IP?

I know this functionality exists in CSF but when server gets hit with distributed email attack it could be hundreds of IPs every minute, CSF blocks them but doesn't take long to hit the limit which would unblock them again. Increasing the limit won't do much because there is just too many IPs...
forums.cpanel.net forums.cpanel.net
Your answer is in the documentation of csf.deny:
# Note: If you add the text "do not delete" to the comments of an entry then
# DENY_IP_LIMIT will ignore those entries and not remove them
Simply append 'do not delete' somewhere on the deny line, i.e.
Code:
123.123.123.123 # do not delete

The first of June 2020 CSF started trying to delete these IP addresses from csf.deny but didn't succeed because of '# do not delete' remark.
CSF was trying this again and again with different IP addresses.
This process was very CPU intensive, about 60% CPU

Solution to stop this process
IP addresses with '# do not delete' in csf.deny
changed from
123.123.123.123 # do not delete
to
123.123.123.123 # lfd: (smtpauth)
CSF removed these changed lines immediately.
And CPU usage was normal again.

Question:
Any idea why this process, process "/usr/bin/perl /usr/sbin/csf -dr [IP.add.re.ss]", did start, does CSF wants to delete these entries after 1 year?
Didn't see this process running on my VPS before.

Thanks so far.
 
The solution you present is a possibility. Normally this should not happen and CSF will not do this by itself.
Another solution is to just remove them manually by editting the csf.deny file.

To clear the csf.deny file without clearing the "do not delete" parts, the csf -df command should be used.
That way CSF will just skip the "do not delete" entry's and stop after having cleard all other ip's.

It's very odd to see the /usr/bin/perl" command in front of this. Just /usr/sbin/csf -dr or rather just csf -dr (because it's in the path) is enough to remove denied ip's except for the "do not delete" ones. Never seen it like that before either.

If you don't have a cron running which is trying to remove ip's, maybe it's of the new feature of Directadmin which has CSF kind of integrated with the Brute force monitor, which might try to unblock ip's after a certain period of time?

That would at least explain the use of the csf -dr command.
 
Richard G said:
The solution you present is a possibility. Normally this should not happen and CSF will not do this by itself.
Another solution is to just remove them manually by editting the csf.deny file.

To clear the csf.deny file without clearing the "do not delete" parts, the csf -df command should be used.
That way CSF will just skip the "do not delete" entry's and stop after having cleard all other ip's.

It's very odd to see the /usr/bin/perl" command in front of this. Just /usr/sbin/csf -dr or rather just csf -dr (because it's in the path) is enough to remove denied ip's except for the "do not delete" ones. Never seen it like that before either.

If you don't have a cron running which is trying to remove ip's, maybe it's of the new feature of Directadmin which has CSF kind of integrated with the Brute force monitor, which might try to unblock ip's after a certain period of time?

That would at least explain the use of the csf -dr command.
Click to expand...

Thanks Richard,
Good thinking, my DirectAdmin has been updated at 05/31/2020 14:30.
As far as a can see no other cron job was running that would trigger /usr/bin/perl /usr/sbin/csf -dr [IP.add.re.ss]
Cron log:
May 31 14:31:01 xxxxxx CROND[25035]: (root) CMD (/usr/local/directadmin/dataskq)
May 31 14:31:01 xxxxxx crontab[25038]: (root) LIST (diradmin)
May 31 14:31:01 xxxxxx crontab[25039]: (root) REPLACE (diradmin)
May 31 14:31:01 xxxxxx crontab[25053]: (root) LIST (a_user)
more of the same
May 31 14:31:01 xxxxxx crontab[25053]: (root) LIST (z_user)
May 31 14:32:01 xxxxxx crond[827]: (diradmin) RELOAD (/var/spool/cron/diradmin)

CPU usage started to increase around that time.

Greetings,
Peter.
 
bdacus01 said:
What is a lot? Seems I read a post about someone having thousands in there which was an issue.


Maybe he copied an old cron from Cpanel?
Click to expand...
Hi Brent,
I inserted about a 100 '# do not delete' lines.
No old Cpanel cron jobs here as far as I know.
I didn't start the processes, when monitoring the DA Process Monitor every 5 seconds a different "/usr/bin/perl /usr/sbin/csf -dr [IP.add.re.ss]" process was started and ended, process ran for a few seconds.

Greetings,
Peter.
 
Graag gedaan.

Try this via SSH just to be really sure:
Code: 
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

If no cronjobs, it might indeed have something to do with the new DA<->CSF integration, you might have to ask smtalk or da support.
Let's hope they see and can confirm or deny this has something to do with the new brute-foce methods.

You can also test yourself.
Got to:
Code: 
/usr/local/directadmin/scripts/custom/
create a file in there called block_ip.sh with this content for example.

Code: 
#!/bin/sh
/etc/csf/csf.pl -td $ip 172800 BFM IP Block
exit 0;

And a file called brute_force_notice_ip.sh with this content:
Code: 
#!/bin/sh
SCRIPT=/usr/local/directadmin/scripts/custom/block_ip.sh
ip=$value $SCRIPT
exit $?;

chown them to diradmin and chmod 700 them.

restart directadmin.

The presence of these file should stop the internal proces with DA and CSF if I understood correctly.

See if the notices still appear. If no, it's the new DA system. If yes... it's something else.
 
Yes that was already known. But it does not state if it uses that automatically on a regular base.
But I suspect that it does, which would explain this sudden behaviour.
 
Richard G said:
But it does not state if it uses that automatically on a regular base.
Click to expand...
Well what about the Settings in Admin Settings > Security Settings. If you have "Remove an IP from the BF blacklist after" and time set seems it would do this automatically?
 
Yep, that would be the thing.
I don't have that in there since I don't use the new build in stuff but still my own custom config at the moment.
 
bdacus01 said:
What is a lot? Seems I read a post about someone having thousands in there which was an issue.


Maybe he copied an old cron from Cpanel?
Click to expand...
Hi Brent,
I inserted about a 100 '# do not delete' lines.
No old Cpanel cron jobs here as far as I know.
I didn't started the processes, when monitoring the DA Process Monitor every 5 seconds a different "/usr/bin/perl /usr/sbin/csf -dr [IP.add.re.ss]" process was started and ended, process ran for a few seconds.

Greetings,
Peter.
Richard G said:
Graag gedaan.

Try this via SSH just to be really sure:
Code: 
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

If no cronjobs, it might indeed have something to do with the new DA<->CSF integration, you might have to ask smtalk or da support.
Let's hope they see and can confirm or deny this has something to do with the new brute-foce methods.

You can also test yourself.
Got to:
Code: 
/usr/local/directadmin/scripts/custom/
create a file in there called block_ip.sh with this content for example.

Code: 
#!/bin/sh
/etc/csf/csf.pl -td $ip 172800 BFM IP Block
exit 0;

And a file called brute_force_notice_ip.sh with this content:
Code: 
#!/bin/sh
SCRIPT=/usr/local/directadmin/scripts/custom/block_ip.sh
ip=$value $SCRIPT
exit $?;

chown them to diradmin and chmod 700 them.

restart directadmin.

The presence of these file should stop the internal proces with DA and CSF if I understood correctly.

See if the notices still appear. If no, it's the new DA system. If yes... it's something else.
Click to expand...
I will look into it tomorrow.
Bedankt.
 
bdacus01 said:
Well what about the Settings in Admin Settings > Security Settings. If you have "Remove an IP from the BF blacklist after" and time set seems it would do this automatically?
Click to expand...
My DirectAdmin Admin Settings > Security Settings for "Remove an IP from the blacklist after 86400 minutes" (60 days).
 
Richard G said:
Graag gedaan.

Try this via SSH just to be really sure:
Code: 
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done

If no cronjobs, it might indeed have something to do with the new DA<->CSF integration, you might have to ask smtalk or da support.
Let's hope they see and can confirm or deny this has something to do with the new brute-foce methods.

You can also test yourself.
Got to:
Code: 
/usr/local/directadmin/scripts/custom/
create a file in there called block_ip.sh with this content for example.

Code: 
#!/bin/sh
/etc/csf/csf.pl -td $ip 172800 BFM IP Block
exit 0;

And a file called brute_force_notice_ip.sh with this content:
Code: 
#!/bin/sh
SCRIPT=/usr/local/directadmin/scripts/custom/block_ip.sh
ip=$value $SCRIPT
exit $?;

chown them to diradmin and chmod 700 them.

restart directadmin.

The presence of these file should stop the internal proces with DA and CSF if I understood correctly.

See if the notices still appear. If no, it's the new DA system. If yes... it's something else.
Click to expand...
I deleted my last reply accidentely.
No strange cron jobs running. Only my normal jobs that don't use csf.
I will look into those scripts later.
 
It might be that automatic one from 60 days which is causing it. You should be able to test this by changing this to for example 3600 (1 hour) to see if it starts trying to do the csf -dr and causes high cpu. If yes, you have the cause and maybe with smtalk can figure out how to solve this. Maybe there is a routine which waits for a certain result in this case.

If it's not cause by this, then I'm out of idea's.
 
Richard G said:
It might be that automatic one from 60 days which is causing it. You should be able to test this by changing this to for example 3600 (1 hour) to see if it starts trying to do the csf -dr and causes high cpu. If yes, you have the cause and maybe with smtalk can figure out how to solve this. Maybe there is a routine which waits for a certain result in this case.

If it's not cause by this, then I'm out of idea's.
Click to expand...
I will look into it.
Thanks.
 
You must log in or register to reply here.
Back
Top