HOWTO: CSF Firewall + LFD Login Failure Daemon

I did it and I keep doing it, but some days later... or a week, it appears there again...

Actually I did chattr -i /usr/local/directadmin/data/admin/services.status, but I believe it's not a way-out. So I guess if you did not face yet, I need to go into details of cron jobs of CSF/LFD
 
I see,

have you tryed to disable it from csf.conf?

Code:
# Enable login failure detection daemon (lfd). If set to 0 none of the
# following settings will have any effect as the daemon won't start.
LF_DAEMON = "1"

Maybe this will prevent the add of lfd as services, or, will just be set to OFF.

Is just a suggestion, never tryed.

Regards
 
Yes, I've got

Code:
[root@server ~]# grep LF_DAEMON /etc/csf/csf.conf
LF_DAEMON = "0"
 
OK, I guess it gets enabled again with cron

Code:
[root@server cron.d]# cat /etc/cron.d/csf_update
SHELL=/bin/sh
25 1 * * * root /etc/csf/csf.pl -u

I'm gonna read /etc/csf/csf.pl
 
i had problem with csf.
After start it almost everything work.
I just create fresh install, don't change anything in configuration excerpt "testing" to 0.
I had problem with mail. After start csf + lfd (with csf -e or from directadmin) the mail don't work. I mean it's not send any mails and mail() function don't work too.

@edit
Resolve.
Need to add ports in TCP_OUT. 587 and 143.

@edit.
No it's not help. In mainlog in exim i had "connection timed out" after i start csf from fresh installation.
 
Last edited:
I've made my own copy of the first post, with a few minor chanes, to fit my own environment, and it works for me, so I sugges trying it to see.

Or visit the official CSF page (configserver.com) and follow instructions there.

Links do occasionally go dead. User littleoak hasn't posted on the forums since 2009, so it's possible he's no longer in business, or no longer using DirectAdmin.

My master file has been changed too much over the years to risk giving it out to anyone, but hopefully someone will respond to the thread here and let us know a current link for a good working file, and I can edit the original post to include it.

Jeff
 
Best thing is to use an original csf.conf from configserver.com because on updates sometimes new options are added to the config.

I took a default file and just adjusted some minor things, like change the amount of times a user can try to login with a faulty password on email etc. and changed banning times etc.

It works already good by default, just check the ports you want to be opened. On a CSF DA install (install-directadmin.sh) ports for Exim, DA etc. are already opened by default. It does not take that much time to wander over the file and make some adjustments you like.
 
I'm agree with Richard, the defaults are enough good for most cases. Just remember to disable test mode in CSF settings after you finish with it.
 
Has anyone succeeded in getting lfd to clamp down on IPs that make repeated attempts on wp-login.php and other such admin addresses on websites? The bot nets have been out in force lately...

If so, how did you set it up?
 
David,

Directadmin is good at a detection of bruteforce on wp-login.php. As soon as you are here you already uses Directadmin + CSF/LFD so let Directadmin to find offending IPs and they will be blocked.
 
Best thing is to use an original csf.conf from configserver.com because on updates sometimes new options are added to the config.

I took a default file and just adjusted some minor things, like change the amount of times a user can try to login with a faulty password on email etc. and changed banning times etc.

It works already good by default, just check the ports you want to be opened. On a CSF DA install (install-directadmin.sh) ports for Exim, DA etc. are already opened by default. It does not take that much time to wander over the file and make some adjustments you like.

YUP but the warning of check PORTs against that default is very important! :) for all if you have changed some default ports yourself, your server could be unreachable then...

If you have you own with / black and ignore whatever list changes also have a look before replacing with the default
 
If you have you own with / black and ignore whatever list changes also have a look before replacing with the default
This applies to *any* configuration file of anything when replacing the config (or important file) by a default config. You should always check and compare. That speeks for itself. :)
 
csf.allow entries being removed after a few hours

I just posted this elsewhere before I found this thread....

I have an entry in csf.allow that looks like:

x.x.x.x # do not delete - Wed Aug 22 23:02:50 2018

that seems to get removed after a few hours. There are other entries that are identical that do not get removed. Any ideas why? I'm pulling my hair out here.
 
Back
Top