lfd being overly trigger-happy

S

Strator

Verified User
Joined
Jan 19, 2011
Messages
279
Hello,

I'm having an issue with lfd which seems minor at the moment but which I know will blow up in my face eventually. Essentially, when I enter the wrong ssh password once or twice, lfd will block me out, even though it is supposedly configured to only block the IP after 15 failed attempts. While at home, I can simply switch to a different IP and unblock myself again, but if this happens on the road, it will cause me major headaches.

This is from /var/log/secure

May 24 05:53:19 server sshd[32114]: Failed password for root from 1.2.3.4 port 49673 ssh2
May 24 05:53:19 server sshd[32114]: Failed password for root from 1.2.3.4 port 49673 ssh2

And this is the corresponding lfd IP block:

1.2.3.4 # lfd: 1.2.3.4 (someserver.com), 15 distributed sshd attacks on account [root] in the last 3600 secs - Sun May 24 05:53:24 2015

At first, I thought it's a bug in WinSCP which I am using for connection, but if WinSCP would really cause so many connections I'm assuming they would show up in the logs, and if they don't show up in the logs, lfd wouldn't know about it either and not block my IP, correct?

So at this point I am assuming it's a bug in lfd itself, but if it is, I'm sure I'm not the only one who has experienced this. Has anyone else seen this? Any other thoughts, ideas, pointers?

I'm using csf v7.69 as a Directadmin plugin. Many thanks in advance!
 
No, nothing else in the logs for that IP. That's also in line with what happened, i.e. I entered the wrong password and was blocked immediately.
 
So at this point I am assuming it's a bug in lfd itself, but if it is, I'm sure I'm not the only one who has experienced this. Has anyone else seen this? Any other thoughts, ideas, pointers?
Click to expand...
If LFD says it's 15 distributed attacks, then something is mostly wrong with the used client (not LFD).

I had this issue once with LFD, with a certain version of Filezilla on a Windows pc causing this some how and once with a mail client on an old version OS X of a Mac machine. In both cases I advised using another client and the problem was gone. The nex Filezilla update did not have the problem either, same as the newer mail client of Mac.

So i would suggest to first try to use something like Putty and see if the problem occurs with putty too, just to see if it might be a Winscp issue.

If it is an LFD bug, it's best to address it at Configserver's forum like Arieh suggested.
 
Ok, but I thought LFD is basically just looking at the logs? So if the logs show 15 distributed attacks even though I just logged in once or twice, then it's the client - but if LFD says 15 distributed attacks even though the logs only show 2, then it's LFD. That was my line of thought, anyway.
 
That depends on the time frame which is set up. If the 15 loggins occur within the timeframe that LFD is monitoring bruteforces, it can still be 15 distributed attacks, even when you tried to login once or twice in the last 2 minutes.
It depends on how this is configured, how long LFD should monitor those kind of bruteforces. You'll have to check your csf.conf to see what's the timeframe used for detection.

If this is not the case, then it can well be a LFD bug, however, in that case it's odd it's not happening with for example putty.
I did not hear of this kind of issue until now.
 
Well again, I thought LFD is just using logfiles. So are you essentially saying that LFD can also ban IPs for login attempts that never show up in the logs?

As a matter of fact, I don't know if it's also happening with putty. I often have several connections and instances of putty and WinSCP open at the same time - it's only this time that I had just booted up and it happened on the first connection with WinSCP.
 
So are you essentially saying that LFD can also ban IPs for login attempts that never show up in the logs?
Click to expand...
No. I was saying that it might be the case that you have to check a longer periode of time in the logfiles (both normal log and lfd log).
If there is nothing to be found, the problem is indeed strange, however it's just as strange that until now it looks you're the only one having this problem.

Every connection you have open, count's as one connection. Could it be you did not close the connections before you closed the pc? It might be they were not closed in Linux and the connection after the boot was seen as additional connections and for that reason seen as distributed attack.
Did you check that?

If it only happened once, I should not be worried about it. If you have this problem more often, it's best to address the issue at the configserver forum.
 
Thanks for the clarification. The parameters of the problem are:

- LFD trigger set to 15 attempts per hour
- LFD actually triggers much earlier (on first or second attempt in at least one proven occasion)
- Definitely no old connections from the previous hour
- As per log file, no other login attempts from my IP logged in the previous hour

I've already posted in the configserver forum, but no replies so far.

PS: And just tested this, deliberately entered three wrong passwords and could still log in just fine on the fourth attempt. Doesn't make it easier if you can't consistently reproduce a problem, does it.
 
Wow, that is indeed a very weird issue.

Maybe you can check the /var/lib/csf/csf.tempban if there are more entries in there.
Or in the /var/lib/csf/stats/iptables_log if it has entry's with the ip in there from which lfd could have taken it.

But if the problem is hard to reproduce, just like you say, it makes it hard to find the cause.

I hope they will find the solution on the configserver forum. If yes, please share it with us/me because I got very curious now. Special problems like intrigue me. :)
 
Hello,

It seems I've faced the same issue today. Directadmin logs show me these 3 lines only:

/var/log/directadmin/login.log-20150610:

Code: 
2015:06:09-16:40:27: '1.2.3.4' 1 failed login attempts. Account 'unknown'
2015:06:09-16:40:29: '1.2.3.4' 2 failed login attempts. Account 'unknown'
2015:06:09-16:40:30: '1.2.3.4' 3 failed login attempts. Account 'unknown'

and CSF/LFD blocks the IP a second later:

Code: 
csf.deny: 1.2.3.4 # lfd: (directadmin) Failed DirectAdmin login from 1.2.3.4 (ES/Spain/user-host-ptr-record-here): 1 in the last 3600 secs - Tue Jun 9 16:40:31 2015

Not much info found:

Code: 
# grep 1.2.3.4 /var/lib/csf/*
grep: /var/lib/csf/backup: Is a directory
/var/lib/csf/csf.dnscache:1.2.3.4|1.2.3.4|user-host-ptr-record-here
grep: /var/lib/csf/Geo: Is a directory
grep: /var/lib/csf/lock: Is a directory
grep: /var/lib/csf/stats: Is a directory
grep: /var/lib/csf/ui: Is a directory
grep: /var/lib/csf/webmin: Is a directory
grep: /var/lib/csf/zone: Is a directory



And nothing here:

Code: 
# grep 1.2.3.4 /var/lib/csf/stats/* -c/var/lib/csf/stats/iptables_log:0
/var/lib/csf/stats/lfdmain:0

But system logs show some other packets were blocked from that IP:

Code: 
Jun  9 16:25:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:25:...:08:00 SRC=1.2.3.4 DST=4.3.2.1 LEN=64 TOS=0x00 PREC=0x00 TTL=50 ID=26672 DF PROTO=TCP SPT=42238 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun  9 16:25:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:25:...:08:00 SRC=1.2.3.4 DST=4.3.2.1 LEN=64 TOS=0x00 PREC=0x00 TTL=50 ID=48640 DF PROTO=TCP SPT=42238 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun  9 16:25:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:25:...:08:00 SRC=1.2.3.4 DST=4.3.2.1 LEN=64 TOS=0x00 PREC=0x00 TTL=50 ID=28991 DF PROTO=TCP SPT=42238 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0
Jun  9 16:25:32 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:25:...:08:00 SRC=1.2.3.4 DST=4.3.2.1 LEN=64 TOS=0x00 PREC=0x00 TTL=50 ID=61264 DF PROTO=TCP SPT=42238 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

But the user had communications and worked fine with FTP:

Code: 
Jun  9 16:21:36 server proftpd[5341]: 0.0.0.0 (1.2.3.4[1.2.3.4]) - FTP session opened.
Jun  9 16:22:34 server proftpd[5428]: 0.0.0.0 (1.2.3.4[1.2.3.4]) - FTP session opened.
Jun  9 16:22:42 server proftpd[5428]: 0.0.0.0 (1.2.3.4[1.2.3.4]) - FTP session closed.
...
...
Jun  9 16:33:39 server proftpd[5341]: 0.0.0.0 (1.2.3.4[1.2.3.4]) - Client session idle timeout, disconnected
Jun  9 16:33:39 server proftpd[5341]: 0.0.0.0 (1.2.3.4[1.2.3.4]) - FTP session closed.

And these lines confuse even more. The only possible scenario as how I see it: CSF/LFD temp-blocked the IP earlier and cleared all records from logs regarding it (why?), and then the IP was blocked permanently because of failed logins to DA. :confused:
 
"Glad" to hear I'm not the the only one observing possible issues. But this is a stupid question - the failed login attempts for directadmin are a total of 6 (1+2+3), or not?

"But system logs show some other packets were blocked from that IP"

Would that be in "messages" or where did you find those?

Unfortunately, I never got a reply to my post over at the Configserver forums.
 
Not much info found:
Click to expand...
Correct, but I stated where you could have a look and that was inside a couple of those directory's.
So the /var/lib/csf/stats/iptables_log file, not the /stats directoryname itself. :)
And maybe /var/lib/csf/csf.tempban but probably there is not much to see in the tempban file except for the ban itself.

1 in the last 3600 secs
Click to expand...
That's odd, since there were at least 3 in the last 3600 seconds.

Are you by any chance using the block_ip.sh (click) tools to protect your systems?
If yes it might have something to do with that some how.

Until now I did not encountered the problem as far as I can see, but I'm a custome block_ip.sh which I customized myself.

Still it can be well a CSF problem, but best way to fix this is post it on the CSF forums. Also a greater chance of more people having the same issue, because also for example the cpanel CSF users are present there.

@Strator: Just "up" your post or give a comment like "nobody any clue?" or something so the post will go as new again.
Maybe if zEitEr is willing to reply to it with his comment an proove that he has the same issue, it might be answered a lot faster.
 
Just to follow up on this, 2 years later I'm still having the exact same issue. I rarely enter the wrong password so it didn't happen to me recently, but I'm pretty sure the problem never went away.
 
Last edited:
You don't have any lfd zombie or defunct processes do you?

But it could be a CSF/LFD issue.
According to this thread here on the DA forums, some others had a kindlike issue with portscanning settings.

If everything else is working fine and no [lfd] <defunct> processes are present, it possibly is CSF choking up.
In that case best thing is to go over to Configserver support forums and ask over there.
However it could be they want to get a debug log from you, so you might have to start csf in debug mode.
 
Well as stated above, I did post over there in 2015 but never got a reply.

NOTE TO SELF: I had $ModLoad imuxsock AND $ModLoad imjournal activated in rsyslog.conf. Deactivated imuxsock now. Other than logging everything twice, I don't think this should be relevant to the problem, but when I return to this thread in 2019, at least I know this wasn't the culprit.

EDIT: The DA thread you linked to is definitely a different issue. My problem is very specifically getting blocked after one bad log in, with neither the configuration settings nor the logs justifying it.
 
Last edited:
Oh sorry, I did not read back that far. :)
Maybe you should have "upped" your post, or maybe you can join up with the other 2 having this problem and make another thread about it.

I also just disovered this thread on their support forums. Which might also be of help to discover what's happening if it's only 1 ip.
And I hope you read this before 2019. ;)
 
Yeah, I read it. ;)

I managed to get myself blocked again after two failed logins. Then I tried again - 7-8 failures, no block. So I can't even reliably reproduce the issue.

As for the the thread from their support forums, from what I understand about iptables (which is, admittedly, not a lot) this is not going to help, because it's not like I don't know why my IP is blocked: It's blocked because it ends up on the deny list. The question is, how does it get there.

From my gut feeling, this isn't a general problem, it must be something that's triggered by something I do, or something I set up. The glitch on their end is that the deny list says I've attacked my own server 15 times, but there are no logs to support this (apart from the fact that I honestly didn't). Since it's not a general problem, however, my thread over there got ignored, and I predict a new one would as well.
 
Check al connections comming from your ( blocked) ip. ( PC's, Smartphones, whatever) first i would recomend maybe a sniffer/logger wireshark...

If your mouse/enter buttons are bad don't know ( don't think so but if they are in 1 click sending ... clicks..) better check above recomendation!
 
Last edited:
You must log in or register to reply here.
Back
Top