Emby admin brute force access

[One2Go 120]

5 hours ago, dexus said:

So please devs, even if it is not a perfect solution or permanent fix, implement this, or remove the alert, as I can imagine many users get grey hairs when they see all the attempts..

Another irritation, is that it fills up the alert log, thus hindering me to se actual issues I care about, as they are moved down the list before i notice them.. 

I second that an implementation in an upcoming release. On the Dashboard you get 4 Alerts being listed and not until you actually look at the alert log do you get an idea of how many attempts and from what IP addresses and locations they came. Hopefully this thread and the replies will be enough to consider an implementation of changing the failed login attempts because of non existing user.

[gutterdone26 9]

Is the 10 login attempts feature something that needs turned on? It doesn't seem to be working for me...

[Happy2Play 9780]

Just now, gutterdone26 said:

Is the 10 login attempts feature something that needs turned on? It doesn't seem to be working for me...

No but it has to be an actual Emby Username.  Do you have that username on your server?

[gutterdone26 9]

I did have admin as a username during the time of the attack, but have since changed it. I've also changed the ports Emby uses since then. I was just curious how the bot or whatever was able to spam me so many times a few days ago if there's a 10 login limit. I'm on 4.8.8.0.

[Happy2Play 9780]

9 minutes ago, gutterdone26 said:

I did have admin as a username during the time of the attack, but have since changed it. I've also changed the ports Emby uses since then. I was just curious how the bot or whatever was able to spam me so many times a few days ago if there's a 10 login limit. I'm on 4.8.8.0.

Not sure as I just took a user and did 10 failed attempts

2024-08-11 10:31:10.395 Error Server: User 1 is currently locked out.

[gutterdone26 9]

Is it case sensitive? Technically it was Admin with a capital A during the attack.

Edited August 11, 2024 by gutterdone26
typo

[Happy2Play 9780]

6 minutes ago, gutterdone26 said:

Is it case sensitive? Technically it was Admin with a capital A during the attack.

Dev would have to confirm but don't think so as my user is has upper case but can log in with lower case.

[One2Go 120]

Look at the following tests found on the 1st page:

It will tell you what happens. If the user name is non existing, the attempts will continue until the bot gives up. If the bot finds a valid user name it will guess the password and after 10 failed attempts the IP address gets locked out.

some of us would like to see Emby handle this differently.

@Happy2PlayHow long is the lockout period?

Thanks

[Happy2Play 9780]

Just now, One2Go said:

How long is the lockout period?

Sorry I don't know as never really knew this existed until it this topic.

[One2Go 120]

13 minutes ago, gutterdone26 said:

Is it case sensitive? Technically it was Admin with a capital A during the attack.

By the way that is the same IP address that attacked my Emby server on a QNAP NAS. I just blocked the IP address on my NAS.

[gutterdone26 9]

1 minute ago, One2Go said:

By the way that is the same IP address that attacked my Emby server on a QNAP NAS. I just blocked the IP address on my NAS.

I was going to block the IP until I looked further back and saw all of these random IPs. This server is kind of a secondary one that I don't use as often and didn't notice this happening right away. I use reverse proxy on my primary server and that one has been fine. Anyway, I've hardened this secondary one a bit and haven't had any more attacks for a few days now. Still not sure why it didn't stop after 10 attempts though. 

[One2Go 120]

2 minutes ago, gutterdone26 said:

I was going to block the IP until I looked further back and saw all of these random IPs. This server is kind of a secondary one that I don't use as often and didn't notice this happening right away. I use reverse proxy on my primary server and that one has been fine. Anyway, I've hardened this secondary one a bit and haven't had any more attacks for a few days now. Still not sure why it didn't stop after 10 attempts though.

It ONLY blocks attempts if it is an EXISTING user name. If Admin is non existing it will try until it is decided they will give up.

By the way the same dates and IP addresses that you found were also in my log. At present no further attempts on my server also.

[gutterdone26 9]

Just now, One2Go said:

It ONLY blocks attempts if it is an EXISTING user name. If Admin is non existing it will try until it is decided they will give up.

At the time of the attack, Admin was an existing username.

[ebr 16169]

39 minutes ago, gutterdone26 said:

I was going to block the IP until I looked further back and saw all of these random IPs

A great example of why blocking by IP isn't as valuable either (in your case, if we blocked the IP, it wouldn't have stopped any of those).  Most of these bots use a random one on each attempt to try and get around that.

[One2Go 120]

14 minutes ago, ebr said:

A great example of why blocking by IP isn't as valuable either (in your case, if we blocked the IP, it wouldn't have stopped any of those).  Most of these bots use a random one on each attempt to try and get around that.

ebr, not every Emby user has the ability to set up a reverse proxy and fiddle with the settings to give permissions to some and block others. If Emby does block after a number of failed attempts for non existing user name the bad actor and does not reply with anything that gives an indication of what the results were for the attempted login, it makes it a bit safer against bots.

Since I had the same IP addresses that gutterdone26 had, my NAS allows me to block IP ranges which I did and it covered those from Singapore and Hong Kong. So please consider changes in the failed login attempts processing.

What is the length of the block out period?

Thanks O2G

[sa2000 674]

On 05/08/2024 at 19:19, rbjtech said:

Other than - Secure Your Server | Emby Documentation - which just discusses TLS - would it be a good idea to have a Knowledgebase with a list similiar to the above on ALL the 'best practice' items the user should do before they even attempt to click the 'remote access' button for emby ?  

@rbjtech I have added a new section of general tips before the existing SSL configuration text.  Updated article is now live https://emby.media/support/articles/Secure-Your-Server.html

[rbjtech 5284]

22 minutes ago, sa2000 said:

@rbjtech I have added a new section of general tips before the existing SSL configuration text.  Updated article is now live https://emby.media/support/articles/Secure-Your-Server.html

Excellent !   Very nice - I think this will help a lot. 

Maybe make this a sticky on the main forum pages alongside the other TLS setup guides etc ?

here ? - https://emby.media/community/index.php?/forum/53-generalwindows/

[rbjtech 5284]

13 hours ago, ebr said:

A great example of why blocking by IP isn't as valuable either (in your case, if we blocked the IP, it wouldn't have stopped any of those).  Most of these bots use a random one on each attempt to try and get around that.

I haven't looked into the details - but the problem is emby is REPLYING that the Auth has failed with a normal http response.  I'm presuming that you are using a 403 or 423 or 429 etc for the 'locked user' message for a brute force valid username.    And the bot is clearly stopping at 10 for this.  So you just need to do the same for the non-valid users and the issue is then likely under control.   Allowing the bot to continue to spam the emby site is just advertising that server is ripe for a more targeted attack as it's protections are obviously weak.     The IP is irrerelevant if the non-user account they are trying to use is returning a 'locked' http response.

[ebr 16169]

4 hours ago, rbjtech said:

 The IP is irrerelevant

But you previously requested us to block by IP - which is what I was responding to.

I'm not saying improvements aren't possible but you calling the current implementation "sloppy" was not accurate nor fair in my opinion.

[pwhodges 2012]

You could use the IP to detect multiple related login attempts on non-existent users, then rather than blocking the IP when the count is reached reply as you would for too many failed logins on an existing user.

Paul

[ebr 16169]

Of course there's lots of things that could be done in addition but when you start talking about tracking things that are not a part of the current Emby install, it gets complicated quickly. 

Blocking an existing user for some period of time can be done by just adding an attribute to an existing user record.  But blocking a user that doesn't exist now means we need a whole new database table and management system for keeping track of things that aren't there.  And then what happens when someone creates a new user - we have to now go look and be sure thy aren't in this list of users that weren't there before.

All of this introduces complexity which translates to future bug potential and also takes time to design and implement.  All for something that, arguably, should be handled at a different layer of access.  Shouldn't we be spending that time on core features of the media system instead?

Like I've already said - future improvements are possible as they make sense within the scope of everything else but the current implementation is not unreasonable and is within the scope of our system.

[One2Go 120]

6 hours ago, ebr said:

All of this introduces complexity which translates to future bug potential and also takes time to design and implement.  All for something that, arguably, should be handled at a different layer of access.  Shouldn't we be spending that time on core features of the media system instead?

Like I've already said - future improvements are possible as they make sense within the scope of everything else but the current implementation is not unreasonable and is within the scope of our system.

Some of us have said the risk and problem could be reduced by the way Emby handles the responses to login attempts to non existing users. You surely must have a criteria of what response you send to what error or infringement. For the sake of the users that just want to share their media with a few friends and don't have the know how on setting up reverse proxies or doing an admin job on a firewall, just DON"T respond at all. I am sure if a legitimate user has problems he will contact the owner of the server. You do not have to worry or find solutions for those kind of users. If you running Emby as a business, then you will have the know how on bullet proofing it, but that is not many of us.

I am eagerly awaiting what the Devs will implement.

[pwhodges 2012]

It seems to me to be clear that Emby handles the attempts to log in with non-existent user names safely.  Given that fact, the main effects of the proposals in this thread would not affect security significantly (if that was an issue, then the attempts before any blocking would remain a problem), but would just be to reduce the amount of logging...

Paul

[Q-Droid 989]

If the devs were to make any change I would prefer to see an incremental delay between failed logins that use the same name or IP instead of blocking, account lock or no response. But even this option could be bypassed somewhat by rotating names and IP addresses. Since the login page is a human facing form it could benefit from a built-in delay at all times to slow down sub-second automated attempts. Something that people wouldn't really notice during normal login.

I would not want to ignore the attempts or keep them out of the logs, which should accurately reflect what is happening in the application.

[rbjtech 5284]

On 12/08/2024 at 13:08, ebr said:

But you previously requested us to block by IP - which is what I was responding to.

I'm not saying improvements aren't possible but you calling the current implementation "sloppy" was not accurate nor fair in my opinion.

As you appear to have an issue with the term sloppy, I had already apologized earlier in this thread.  But imo, on a self hosted internet based system,  there is a level of basic protection and information you need to provide as Emby is opening up that network.  You, as a supplier of the software have a responsibility to do this.   If you choose (as you have done in this instance) to do what you consider 'acceptable' then fine - but don't then get involved with logging at the same alert level for things which you are considering you are not responsible for.   The result is people raising the alerts on the forums ..   hence this thread.. 

Perhaps put any effort into reporting to syslog and then let the user decide.   I would block by ip - and it would also then get reported to potentially get added to a blacklist so everyone can benefit... 

Edited August 13, 2024 by rbjtech