Emby admin brute force access

[Psychotik 1]

Someone is clearly trying to hack into my server right now with brute force. I can see them try and try. Is there anyway i can protect myself? A 2 factor authentication for example. I remote acess into my server during commute and let familly members access it + 2 close friends.

 

Here a pic of him trying to gain acess. Started trying at 6am.

[richt 94]

You should consider fail2ban as it helps protect against brute force attacks.  If you aren't already using SSL and a reverse proxy server, consider SWAG docker as it includes fail2ban.

https://github.com/fail2ban/fail2ban

https://docs.linuxserver.io/general/swag/

[Psychotik 1]

Okk thx for the help. Ill research this stuff and try to get good at it

[kbijvank 57]

I have the same but from usernames I don’t know. Are there any users that are experiencing the same? Just gathering info so to see if there is a scope to it.

[rbjtech 5284]

Emby has built in brute force protection - it should be locking 'admin' for a peroid after I believe it's 10 failed attempts.

It's not as flexible as using a reverse proxy and f2b etc, but it achieves the same result to stop a constant brute force.

@Luke@ebr @softworkzFYI

Edited August 5, 2024 by rbjtech

[rbjtech 5284]

2 hours ago, Psychotik said:

 Is there anyway i can protect myself? 

 

yes 

1. Change the name of any 'admin' account to something else that is not admin - if an attacker doesn't even know the account name, then they cannot even attempt to login.

2. Ensure the clients are hiding all the usernames and set it to only show those that have previously logged in.

3. Disable remote 'Admin' access (or whatever you have called it).  Do you really need to admin emby remotely ?  If yes, then there are secure options to do this.

4. Ensure you use a nonemby admin account for all your 'normal' activity.

5. Ensure all non-admin accounts have the correct permissions setup - and give least priviledge - ie if they don't need delete, then remove it !

6. Try and ensure you are using https - and ideally a reverse proxy and use default ports. (80 redirect to 443)

7. If not using a reverse proxy, change the default ports to something not commonly in use.

8 ...

There are LOADS more but this will get you started ..

MFA is actually well down the list - there is zero point having that until your security foundations are solid ..

 

@sa2000Other 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 ?  The 'out the box' security profile for emby is pretty shocking tbh ...

 

Edited August 5, 2024 by rbjtech

[Psychotik 1]

5 hours ago, kbijvank said:

I have the same but from usernames I don’t know. Are there any users that are experiencing the same? Just gathering info so to see if there is a scope to it.

No, it's my main account doing it (admin). 

[Psychotik 1]

4 hours ago, rbjtech said:

yes 

1. Change the name of any 'admin' account to something else that is not admin - if an attacker doesn't even know the account name, then they cannot even attempt to login.

2. Ensure the clients are hiding all the usernames and set it to only show those that have previously logged in.

3. Disable remote 'Admin' access (or whatever you have called it).  Do you really need to admin emby remotely ?  If yes, then there are secure options to do this.

4. Ensure you use a nonemby admin account for all your 'normal' activity.

5. Ensure all non-admin accounts have the correct permissions setup - and give least priviledge - ie if they don't need delete, then remove it !

6. Try and ensure you are using https - and ideally a reverse proxy and use default ports. (80 redirect to 443)

7. If not using a reverse proxy, change the default ports to something not commonly in use.

8 ...

There are LOADS more but this will get you started ..

MFA is actually well down the list - there is zero point having that until your security foundations are solid ..

 

@sa2000Other 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 ?  The 'out the box' security profile for emby is pretty shocking tbh ...

 

 

 

Thanks ill try all theses!

[Psychotik 1]

Update: seems the attack stopped around 1pm. Maybe they got bored of guessing my password. Or emby protection kicked in? Hopefully they gave up.

I suspect maybe they got my email from some place and were trying to guess my password.

[pwhodges 2012]

I don't suppose anyone has given a single thought about you, your password, or giving up.  Most likely a program has been fed your details (maybe deduced from scanning), along with countless others, and tries for a while on each one before automatically moving on to the next.  Another will probably come by some time in the future.

Paul

[One2Go 120]

Since I also had yesterday 4 failed login attempts on my QNAP NAS for user Admin, I thought I post here for a "Best Practice" item.

I only have 5 remote users plus myself when I go on vacation. To minimize any damage from hacking, I have no user account named "Admin". However I would like some comments on the changes I am about to make to the profile of users. I ONLY manage the server from the local network and if I am away and management of the server is needed, it has to wait until I am on the local network. So here is what I am trying to implement and the User Names are for clarity only. Any comments are welcome. Thanks

User for managing the server (Local Admin)

Finally the Remote Users with their permissions.

Edited August 6, 2024 by One2Go

[visproduction 315]

1. I agree that changing the access port to something other than the standard 8096 may help, as mentioned above.
2. Routers also have limited number of IP number blocks.  Typically the attacker uses so many IP address, that blocking a lot does not help.
3. What about creating a hidden access page with some image that the user clicks on?  The link is javascript incripted so no bots can find or even click on the IP or SSL address.  Then you could change the port monthly, if you want.  Since everyone is accessing the site through the hidden page link, you can update your port address on the server and on the page link and users will automatically get through, but any hacked IP address will fail because it uses an older port.  This would be only one extra click for the users, and you could use the access page to promote whatever you like that is happening currently with your media collection.  You can also add some background theme image or whatever to the new landing page.
   
   Hope that helps.

Edited August 6, 2024 by visproduction

[rbjtech 5284]

@One2Go

Did you see these in this thread ?

 

 

Edited August 6, 2024 by rbjtech
edit - removed previous link - it's likely to be unrelated

[One2Go 120]

19 minutes ago, rbjtech said:

@One2Go

Did you see these in this thread ?

These new attacks are possibly related to this -

https://www.bleepingcomputer.com/news/security/surge-in-magniber-ransomware-attacks-impact-home-users-worldwide/

 

I read this thread and implemented the first 5 of your suggestions. My posting was related to your point 3 "Disable remote 'Admin' access". Your point is very well taken, why would you want to do a remote admin. Therefore my screenshots, one account for accessing Emby when traveling and one account when doing admin tasks when at the local network. All deletions of libraries has been disabled for remote users.

The bleeping computer article talks about encrypting files, while I have taken steps to prevent that on the NAS level, these attacks are only at the Emby server not at the NAS. Can they encrypt files if they only have playback permissions on Emby?

Edited August 6, 2024 by One2Go

[rbjtech 5284]

54 minutes ago, One2Go said:

I read this thread and implemented the first 5 of your suggestions. My posting was related to your point 3 "Disable remote 'Admin' access". Your point is very well taken, why would you want to do a remote admin. Therefore my screenshots, one account for accessing Emby when traveling and one account when doing admin tasks when at the local network. All deletions of libraries has been disabled for remote users.

ok great - I'm glad it's been useful to you.

54 minutes ago, One2Go said:

The bleeping computer article talks about encrypting files, while I have taken steps to prevent that on the NAS level, these attacks are only at the Emby server not at the NAS. Can they encrypt files if they only have playback permissions on Emby?

So I've done some more research on the link I provided - and it's not a remotely executable vulnerability - thus it's not going to impact emby.   I've removed the link.   

It is odd through that there is a flurry of activity with people reporting uninvited access attempts - something that emby need to keep an eye on - but with the low numbers of people reporting it - I don't think it's widespread.   I don't see any attempts, but then again, I don't use emby ports..

[adminExitium 355]

Depending on compatibility, another option may be to setup Tailscale and add your Tailscale Network as a LAN network in Emby so you can still administer it remotely via Tailscale.

[Jdiesel 1431]

This should serve as a reminder to sanitize, now a built in feature, your emby logs or not post them publicly at all.

[Neminem 1518]

I'm wondering if you guys use emby in your dns name ?

Something like emby.mydomain.org

I used to do that and sometimes have unwanted visitors, until I changed the dns name.

to something like sdkfjhs.mydomain.org

[rbjtech 5284]

Simply put - for any service that is 'listening' on the internet - it will be 'found' and probed periodically by bots and all possible information gathered from responses in the packet headers etc.

This is why its important to not give away any unnecesary or revealing information.   Responding to TCP 8096 ?   Then it's either JF or Emby.  Look a tiny bit deeper on the packet URL response - it's easily determined that it's emby.  Bingo - you don't need an unsanatised emby log, you don't need a DNS name .. all the information you need to determine the 'service' is openly available...

Edited August 7, 2024 by rbjtech

[One2Go 120]

On 8/5/2024 at 2:10 PM, rbjtech said:

Emby has built in brute force protection - it should be locking 'admin' for a period after I believe it's 10 failed attempts.

It's not as flexible as using a reverse proxy and f2b etc, but it achieves the same result to stop a constant brute force.

It looks like that it DOES NOT lock out failed admin login attempts after trying a number of times. I went to the Alert log and found out that attempts to login as admin and username from one single IP address has been going on for hours. I gave up after counting 20 failed login attempts. The entire trying to log in started on 8/5/2024, 2:49:00 AM prior to that, nothing. This is from the Alert log:

Started at:
Failed Login Attempt from username on QNAP-NAS
34.100.169.207
8/6/2024, 11:08:35 PM

Ended after 49 attempts at:
Failed Login Attempt from username on QNAP-NAS
34.100.169.207
8/6/2024, 11:10:58 PM

Than followed by the username of admin for countless attempts every few seconds:

Started again at:
Failed Login Attempt from admin on QNAP-NAS
34.100.169.207
8/6/2024, 11:11:39 PM

Ended too many attempts to count at:
Failed Login Attempt from admin on QNAP-NAS
34.100.169.207
8/7/2024, 12:05:07 AM

How can Emby allow so many failed login attempts from a single IP address? Is there a setting that I missed or is the blocking something that needs to be implemented? I am at the latest version of Emby.

@Luke@ebr@softworkzPlease leave some advise or answers to this occurrence of mine.

Edited August 7, 2024 by One2Go

[rbjtech 5284]

Ah - a sloppy user based implementation - it only locks out the user if the username is correct and password is wrong.

It doesn't lock out if an incorrect username is used - agree 100% ... 

If I use Admin - no lockout, if I use test (a quick account I just created) then I do get lockout ..

 

User Admin (does not exist..)

User test - does exist - locked out after 10 tries.

ps - don't care about showing the client IP - this is from a VPN.

-edit-

At leasy my Pushover alerting is working, as it went balistic when testing this.  Both 'Admin' and 'test' sent the alert to my phone using the Emby Notifications.

-edit 2-The issue is going to be that while locking a user is relatively easy - Emby is going to have to blacklist the IP (which you can do in GUI today) - the issue is I'm not sure if that can be dynamically blocked, as any network configuration change usually needs a reload ... lets see.

Edited August 7, 2024 by rbjtech

[One2Go 120]

6 minutes ago, rbjtech said:

Ah - a sloppy user based implementation - it only locks out the user if the username is correct and password is wrong.

It doesn't lock out if an incorrect username is used - agree 100% ... 

If I use Admin - no lockout, if I use test (a quick account I just created) then I do get lockout ..

I thought that the protection should have been better implemented for user login when attempts are failing. On my NAS I can specify that after like 5 attempts the IP address is banned for 24h or longer. Don't know if the implementation for that in Emby would be difficult.

[ebr 16169]

18 hours ago, rbjtech said:

a sloppy user based implementation

Completely unfair, IMO.  It is effective for what it needs to do and within the scope of our product.  If the user doesn't exist, what would be locked out?

You might say something like IP address but my response would be that would have limited effect and, also, that level of blocking is better left to something at the network level.

If they try forever with an invalid user, what is the harm?  They'll never get in... so, aren't they effectively "locked out" of Emby?

[One2Go 120]

30 minutes ago, ebr said:

Completely unfair, IMO.  It is effective for what it needs to do and within the scope of our product.  If the user doesn't exist, what would be locked out?

You might say something like IP address but my response would be that would have limited effect and, also, that level of blocking is better left to something at the network level.

If they try forever with an invalid user, what is the harm?  They'll never get in... so, aren't they effectively "locked out" of Emby?

You do have a point with your assumption, however do the repeated attempts have an impact on the NAS performance when someone is streaming? Do the Blacklist function prevent the person from attempting to login?

Since I have only a few users I have toyed around with the idea of using the Whitelist function after monitoring the situation for awhile. The attacks have since then stopped.

Please let me know the answers to the two questions.

[ebr 16169]

Just now, One2Go said:

do the repeated attempts have an impact on the NAS performance when someone is streaming?

Even if we put the IP on a "blocked" list, the attempts would still be getting to and being processed by your Emby server - it would just be failing a different way other than the user not existing.  The net effect will be exactly the same.  That's why, doing stuff at the IP level is better left to the network layer somewhere else - then that traffic never even gets to Emby.

2 minutes ago, One2Go said:

Do the Blacklist function prevent the person from attempting to login?

Sorry, I don't really understand that question.