Bruce Force Monitor skiplist refuses entry

[sekorulez]

We use the brute force monitor on our directadmin installation. Great tool to monitor attacks.

When there are > 100 attacks we get an email every hour. If it's an attack on a none existing account I would like to skip those. Therefor there is a great skiplist! However the system doesn't always allow me to add a value to the skiplist. When I add 't.lastname' to the skiplist it refused. 'Error adding value(s) to skip list. Provided value is not a Username of Email address'.

I believe this is a bug. It's true that a login with the format 't.lastname' is not a valid username in directadmin. However this does not mean attackers will not try in there ignorance.

Attackers will enter enything they like as a username. So all different types of usernames exists in the 'Failled logins: Usernames List'. However the skiplist only accepts emails of valid usernames on it's list. Resulting me on getting a email every hour on something I would like to ignore as the attempted login is on an account that does not exist. There is no way for me to prevent this attack as it keeps coming from different email addresses.

A couple of years ago I already tried to send in a request for this as I believe this is a bug! It's was refused as it was discrubed as correctly working feature. To me this is not a feature but an annoyance.

How do I report this so the directadmin support team understands this a bug? How do I explain that you cannot apply validation on input from outside attackers. They do not apply your rules. Outside attackers will enter anything they want as username when they attack. So the skiplist should allow any string to be added to it. It's for me as a server manager to decide what I put on the skiplist. Not for directadmin do judge it! I think putting input validation in the skiplist is not correct. Please help me with this. This is flooding my mailbox. I do not wish do disable the BFM as it is a great feature for early detection of realy dangerous attacks.

Sebastiaan

 

[Richard G]

I believe this is a bug. It's true that a login with the format 't.lastname' is not a valid username in directadmin. However this does not mean attackers will not try in there ignorance.

This is not a bug, it's working as designed. You can't trace a user which does not exist on the system, so logically the system can't find that user or email address.
So the answer you got in the past, is still currently valid.

It's correct that attackers will not try non existing accounts, but that is not DA's task to provide firewall skiplisting. It's already great they give the skiplist of attacks to existing users as a service.
There is no way to bring this to DA so they understand this is a bug, because it is no bug. It's better that you try to understand that it is no bug.

Next to that, attacks on non existing accounts are totally not interesting because they don't result to anything anyway, so there is no reason for any panel, including DA, to provide some way of stopping notifications for that.

It's the firewall who is sending you the emails, so if you want to stop being bothered, then you should tell the firewall to stop those messages.
Edit your /etc/csf/csf.conf file and disable notifications for bruteforcing there.
The detection and protection will keep working, you just don't get any notifications of it anymore.
LF_EMAIL_ALERT = "0"

Don't forget to restart CSF/LFD afterwards.

 

[sekorulez]

Hi Richard,

Thank you for your response. First of all let me say that I do wish to better understand how it works, and why it works the way it does. I currently don't understand it. I am thankfull for any help you or anybody can give on that. I do not wish to be stubborn of to make you feel threatened or attacked. I'm a software developer myself. I always like for software to support what I need, to make my life easier. And I am searching for that right now. But this always means learning. But I also can relate to de feeling of customers telling me how the product should work according to them which is not what is in intended for. I can relate to the frustation it can give. I do not wish to frustrate you. I just wish for the product to support my work as a system admin.

What I understand is that both CSF/LFD and directadmin play I role in this. What's not really clear to me who is responsible for what part in this process. For what I see it seems CSF/LFD monitors and combines the log of failed attempts (the source is EXIM in this case). And driectadmin then alerts me if something is wrong. But your explanation seems to contradict this.
What i do see is that directadmin presents me with some controles. I expect these to help me. I therfore think directadmin is sending alerts. Turning of the email alert is not really a good solution. Because I need the alert on when new accounts are being attacked.

Let the try to explain what I do:
The BFM is a great help in detecting possible weakness in your system. For instance if i see these accounts are beeing attackes I could respond to that:
name login failures
sebastiaan 200
root 23
s.lastname 10
[email protected] 12
[email protected] 12

If I decide that the attack on user 'sebastiaan' is not interesting to me... (this user does not exist) I can put this user on the skip list. I then no longer receive reminders that failed login attempts occur. The systeem still register them, but no alert is send. If then a fews days later I receive a new waring I look at the overview again.

name login failures
sebastiaan 250
root 27
s.lastname 101
[email protected] 125
[email protected] 123
rembrandt 123

This time multiple rows are > 100 login failures. 's.lastname', '[email protected]' and '[email protected]' are not interesting (they all don't exist). I wish to add all to the skip list so the system will no longer notify me about them. However '[email protected]' and '[email protected]' are added to the skiplist. But 's.lastname' is not. I do not understand why???
'rembrandt' could be a real account. I could then rename it or check if the password is strong. If I have many attacks from one 1 ip. I block it. So the alert is important to take action when needed. I cannot turn of the alert in total. I just want the system to stop alerting me on 's.lastname'.

Is the list of failled login managed/used by directadmin or by CSF/LFD?
Is the skiplist managed/used by directadmin or by CSF/LFD?
Where can I find these lists on my system

If I understand you correct CSF/LFD is sending me the email. However the email I receive is because a message was placed in directadmin:

-------------------
A new message or response with subject:
Brute-Force Attack detected in service log on User(s) s.lastname
has arrived for you to view.
Follow this link to view it:
https://xxx.domain.com:2222/CMD_TICKET?action=view&number00001231&type=message
================================
Automated Message Generated by DirectAdmin 1.63.3
Do Not Reply.
--------------------

This to me looks like directadmin is sending me a message about the number of login failures beeing over > 100 and the name s.lastname is not on the ignore list. So to me it seems that placing s.lastname on the ignorelist is the sollution. Is that really a wrong idea?

Is there a way for me to prevent these logins on Exim? Knowing this is a server that is used for email and closing exim is not a valid sollution.
Is there a different wat for me to configure CSF/LFD or directadmin to tell it not to monitor things I already checked/verified that are harmless?

Thank you for all the effort in helping me to understand.

Sebastiaan

 

[sekorulez]

This is not a bug, it's working as designed. You can't trace a user which does not exist on the system, so logically the system can't find that user or email address.
So the answer you got in the past, is still currently valid.

I can put anything on the skiplist. For instance 'axqir', 'contact', 'hox', '[email protected]'..... even if it is not a user or email on the directadmin system. It seems to me the skiplist is not connected to directadmin or it's users. So the failed login does contain users that are not on the system. So it is tracing users that are not on the system. Your explanation does not help me to understand it.

 

[Richard G]

I do not wish to be stubborn of to make you feel threatened or attacked.

Don't worry. I don't feel threatened or attacked that quickly and I know that just like everbody, I also make mistakes.

It seems to me the skiplist is not connected to directadmin or it's users.

And that's one of my mistakes then. Sorry, from some of the lines you wrote, and thinking about DA, I really thought that the skiplist only could contain valid (existing) usernames or email addresses, so this seems not the case.

But 's.lastname' is not. I do not understand why???

I'm trying to understand what exactly is going on. I do understand why this is not entered in the skip list as it contains a dot.
Usernames do not contain a dot and it's not an email address either.
But I would like to understand where exactly a name like that is coming from. You say from exim logs?
I've never seen something like that before so I'm also eager to learn and would like to know how this looks. So I checked and it seems DA is looking at the "set-id" statement in the log line.

Is the list of failled login managed/used by directadmin or by CSF/LFD?

Both check the logs, as far as I know only BFM of DA is managing the lists.

Is the skiplist managed/used by directadmin or by CSF/LFD?

That is managed by Directadmin. We had something like that already in the early days before CSF was kind of integraded.
You probably find it here:
/usr/local/directadmin/data/admin/brute_skip.list
I don't know if it would work, if you would put that l.lastname in there manually. Might be worth a try.

It's in your case probably Directadmin sending you the mail. It's from the DA notice anyway, but you have to look inside this message:
https://xxx.domain.com:2222/CMD_TICKET?action=view&number00001231&type=message
it will declare what is happening and you can see if CSF or DA is triggering this message. But in this case I think I was wrong and Directadmin is sending the messages you're talking about.

Then about the skiplist. Normally names with a dot don't exist if they are not email addresses. Maybe that's the reason that it's working as designed. I havent seen it ever before that attackers used it that way in my BMF monitor. Which will not mean it won't happen, but I have the impression it's not widely used (yet). I could be wrong.

However, in that case, if the skiplist should be adjusted, then that would mean wildcard should be added. Because if an attacker could use something like t.lastname they can also use 23@@.!o[d too, so how do you want to skip that?
Because they can easily change any character to something else and keep you busy with the skiplist.
This also means, since they can put in the set-id what they want, it's almost not doable to block this with custom Exim programming either. Because suppose you block a dot, how about [email protected] names? I think that will be quite hard to achieve something good.
So I think the way it works now might be the best way to skip most, but I'm no developper or programmer.

At a certain point after many years, I had enough of all those messages and decided to stop the whole BFM mailing from DA anyway. Because either CSF or DA will provide a block for the abusers.
If some customer complaints, then I have a look, see whats wrong and mostly it's a new device with a wrong password causing the issue.

Unless you have questions I can answer, I won't reply again, to give others a chance to maybe give a better explanation or maybe have idea's on how to fix this.

 

[Richard G]

Because I need the alert on when new accounts are being attacked.

Out of curiosity... Why, what's the benefit of that? Can't do anything about attacks anyway, so I'm curious as to why this is interesting.

 

[sekorulez]

Hi Richard,

Thank for your honest response. It's clear to me the message is send by DA. That's why I marked it as a bug in DA. The message itself contains this if you look under my messages.

------------------
A brute force attack has been detected in one of your service logs.
User s.lastname has 237 failed login attempts: exim1=237
Check 'Admin Level -> Brute Force Monitor' for more information

Securing DirectAdmin | Directadmin Docs

DirectAdmin Knowledge Base

help.directadmin.com

------------------

To me the problem and the solutions seem simple. De BMF reads the logs. For example here is a section as shown in 'failed logs' (names are chaned to protect privacy). Apperently '[email protected]' is a valid way to logon to exim. So is 's.lastname'.

2021-12-19 18:21 (2)	58.127.229.119	s.lastname	1	exim1	2021-12-19 18:21:00 login authenticator failed for ([127.0.0.1]) [58.127.229.119]: 535 Incorrect authentication data (set_id=s.lastname)
2021-12-19 17:54 (2)	221.155.89.58	s.lastname	1	exim1	2021-12-19 17:53:50 login authenticator failed for ([127.0.0.1]) [221.155.89.58]: 535 Incorrect authentication data (set_id=s.lastname)
2021-12-19 17:48 (2)	217.126.125.57	s.lastname	1	exim1	2021-12-19 17:47:26 login authenticator failed for 57.red-217-126-125.staticip.rima-tde.net ([127.0.0.1]) [217.126.125.57]: 535 Incorrect authentication data (set_id=s.lastname)

2021-12-19 18:21 (1)	185.142.208.143	[email protected]	1	exim1	2021-12-19 18:20:51 login authenticator failed for gateway.voelkl.cz ([127.0.0.1]) [185.142.208.143]: 535 Incorrect authentication data (set_id=[email protected])
2021-12-19 17:54 (1)	82.165.182.91	[email protected]	1	exim1	2021-12-19 17:53:29 login authenticator failed for ([127.0.0.1]) [82.165.182.91]: 535 Incorrect authentication data (set_id=[email protected])
2021-12-19 17:48 (1)	71.125.72.235	[email protected]	1	exim1	2021-12-19 17:47:02 login authenticator failed for static-71-125-72-235.nwrknj.fios.verizon.net ([127.0.0.1]) [71.125.72.235]: 535 Incorrect authentication data (set_id=[email protected])

On both cases BFM counts the number of failed attemts en list them.

When I put them on a skiplist it should not matter what the contents is, it is simply a string of text. No wildcarding is need. Simply the string used on the login. The reason the system makes a distinction is because it needs to know if it's a ip adres or a username. Both values endup in the same skiplist. But the ip adres and username come from a different source in the log, so a different skip action. The both filter on different fields. BMF uses therefore 2 lists, one with ip's and one with usernames.

The only check the system should do is...is this an ip.... then handle it as an ip....else it's the username that is skipt. That it applies it's own rules on what a username is, is wrong in this case. As the source is the exim log, not the usernamerules of DA should be applied.

DA already nows 's.lastname' is used as a username as it is shown in 'Failed logins: username list'. It's already categorized it as a username.

Therefore I qualify it as a bug! It's a check on the wrong place.

I will look and see if there is script used so I can point out the exact location of the bug, and the needed fix. I will also check and see what happens if I update the skiplist mannually.



Stopping messages al together because they come to ofter is a wrong way to handle things, I think. I would like to see the message first and the configure the system not to reiceve the ones I'm not interesseted in. This always allows the system to send messages on things I did not anticipate on, or did not see yet. New types of attacks for instance. Therefore i'm asking for a fix of the skiplist system, as I do not want to stop all messages. But I also do no wish to received 20 messages a day on something that is not relevant.

The servers we use are not used for customers just our own systems. So I know all the usernames. Attempts to logon a none existing user is nothing worry about. But attacks on a real user could potentially be succesfull. Even at 3 attempts every 5 minutes. Therefor I always want to receive a warning about login attempts. So I can see if it's on a real user and perhaps change the username.