Emby admin brute force access

[One2Go 120]

1 hour ago, ebr said:

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.

Sorry, I don't really understand that question.

You answered my question by saying "would still be getting to and being processed by your Emby server" even if their IP address is in the Blacklist and I presume it will be blocked at a later time once the user name is valid. As @rbjtechpointed out after a valid user name is found, that attempt to guess the password will than be blocked after 10 failed attempts. Any chance to reduce that to 5 like my NAS does?

You mentioned that the blocking would be best done on the network level. My NAS is NOT being targeted, just the Emby server. Again, I presume that once the Emby's open public port is found, now the login attempts start on Emby. What is the worst scenario when ALL users ONLY have the permissions of "allowing media playback, media downloading and conversion as well as audio and video transcoding plus changing container formats"? NO remote user has delete or server managing permissions.

A couple of years ago, QNAP released a flawed feature that allowed bad actors to gain root control of the NAS. At that time I took precautions to make sure that the risk of my NAS being compromised is at an absolute minimum. My router and NAS have some protection and I don't want to go full Monty on reverse proxy and other protection that requires knowledge above my pay grade. I started with early versions of Media Browser and so 99% of playback is over the local network, just 5 remote users have access to my Emby server.

To summarize, it is my understanding that only the Emby server is being targeted through the open port and not the NAS and network itself, is that correct?

I am posting this as it would be good to create a "Best Practice FAQ" listing, with some of the suggestions of helping with a brute force attack. From the beginning of using Emby I had changed the default port values.

Edited August 8, 2024 by One2Go

[pwhodges 2012]

1 hour ago, One2Go said:

You mentioned that the blocking would be best done on the network level. My NAS is NOT being targeted, just the Emby server.

The contact is coming through the NAS networking layer; by stopping it there, less resources are getting used.

If a thief wants to steal your TV, you could either bolt it to the floor to prevent them taking it, or you could secure your house so they can't come in at all.  Stopping the intrusion at the NAS networking level is like locking your house doors.

Paul

[rbjtech 5284]

4 hours 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?

Emby has a Whitelist/Blacklist function for this exact purpose - blocking/allowing IP's at presumbably the application layer.

Yes I agree the perimeter f/w is the place to do this (as I do) but not many people are going to have a reverse proxy, yet alone the ability to setup fail2ban etc in a dmz.

So Emby are logging the Auth error forever and showing this in the Alerts - but are providing no solution to the user ?

Either don't log them/alert them (they are, as you say, effectively ignored) or block the IP to derisk future attempts.

'Sloppy' was probably a bit strong, so for that I apologise, but implementing a brute force lockout mechanism (4.8.0.48 - User Auth Brute Force Password Lockout) but ignoring attempts from anything other than valid users - is not forfilling the concept of stopping brute force attempts because you are replying the Auth has failed - forever.   ie I'm still here.

Brute force should not reply, thus the attacker moving onto other targets (the bot will see no response) ...    Emby even has the mechanism to do it (the blacklist option) and I'm assuming it simply drops the connection, like a firewall would ?

So for a more 'effective' solution - maybe emby need to implement the IP side of brute force and not just the limited user based .. ?

Edited August 8, 2024 by rbjtech

[One2Go 120]

48 minutes ago, pwhodges said:

The contact is coming through the NAS networking layer; by stopping it there, less resources are getting used.

If a thief wants to steal your TV, you could either bolt it to the floor to prevent them taking it, or you could secure your house so they can't come in at all.  Stopping the intrusion at the NAS networking level is like locking your house doors.

Paul

I like your illustration about locking down the house, how would that be implemented on the NAS? What suggestions do you have in mind? Remember I am on the QTS OS a version of Linux and my Linux skills are limited at best. In the log files that I have on the QNAP NAS there are no entries from any of those IP addresses and it may be that my understanding of communication from the Internet to my NAS is not thorough enough. I have 3 QNAP boxes and all of them have been working flawless for many years to the point where two of them no longer receive QTS updates as they are EOL. The one that has the Emby server is still receiving updates and feature releases.

[One2Go 120]

On the NAS under the Security Entry there is a place for blocking connections. Would that be sufficient enough to enter IP addresses or ranges to block connections to the Emby server?

 

[pwhodges 2012]

That's a good place to do it, though of course it needs manual setup and maintenance.

NAS systems are generally rather locked down, so I don't know how easy it would be to install a program to automate this, like fail2ban.

Paul

[rbjtech 5284]

IMO - A manual method is simply not maintainable.    It needs to be done in combination with a reverse proxy, fail2ban for synology etc - but this all needs experience setting it all up to work with emby.

Hence by original point about emby providing the full solution ..

[One2Go 120]

Thinking some more about this, I take on board the point that when there is a login attempt with a user name that doesn't exist, than provide no feedback to the bad actor and "simply drop the connection, like a firewall would". I don't know how feasible that implementation is though.

I don't mind the method of maintaining the blacklist manually as it allows me to enter IP address ranges. In the above example I have blocked a large chunk originating in Singapore and India. This failed attempt of logging in in all the years has just started 4 days ago. Prior to that for 5 years nothing, nada, zip, niente.

Thanks for your help and assistance and hopefully a future version of Emby will improve this failed in logging attempt handling.

[rbjtech 5284]

1 minute ago, One2Go said:

Thinking some more about this, I take on board the point that when there is a login attempt with a user name that doesn't exist, than provide no feedback to the bad actor and "simply drop the connection, like a firewall would". I don't know how feasible that implementation is though.

I don't mind the method of maintaining the blacklist manually as it allows me to enter IP address ranges. In the above example I have blocked a large chunk originating in Singapore and India. This failed attempt of logging in in all the years has just started 4 days ago. Prior to that for 5 years nothing, nada, zip, niente.

Thanks for your help and assistance and hopefully a future version of Emby will improve this failed in logging attempt handling.

FYI - on most reverse proxies - you can implement Geo Blocking - which automatically drops all traffic from every country apart from your own and those you know you need connections from.   While this stops a LOT of traffic, a simple VPN can get around it... unless of course, you also block all known VPN ranges ... and around and around we go.  

[rbjtech 5284]

6 minutes ago, One2Go said:

Thinking some more about this, I take on board the point that when there is a login attempt with a user name that doesn't exist, than provide no feedback to the bad actor and "simply drop the connection, like a firewall would". I don't know how feasible that implementation is though.

I've never used the Emby blacklist - but it's easy enough to find out by using Wireshark.  I suspect emby are simply not replying to the http request, as oppose to dropping the TCP session, but it achieves the same thing - the end user not getting a response.

[Q-Droid 989]

20 hours ago, One2Go said:

You mentioned that the blocking would be best done on the network level. My NAS is NOT being targeted, just the Emby server. Again, I presume that once the Emby's open public port is found, now the login attempts start on Emby. What is the worst scenario when ALL users ONLY have the permissions of "allowing media playback, media downloading and conversion as well as audio and video transcoding plus changing container formats"? NO remote user has delete or server managing permissions.

Your Emby server may not be the target, only the entry point because it's the path that's detectable by the intruder. The goal could very well be to enter and discover other paths into your network. Even if this one in particular only wants access to Emby you have to think big picture and protect the whole environment from the best vantage point.

15 hours ago, One2Go said:

Thinking some more about this, I take on board the point that when there is a login attempt with a user name that doesn't exist, than provide no feedback to the bad actor and "simply drop the connection, like a firewall would". I don't know how feasible that implementation is though.

Which is why Emby is not the app to handle this as it doesn't control the network interface. For Emby to handle this a connection has to be attempted and established and already too deep inside your network, too late. The barrier ought to be the first line of defense and at or closest to the WAN interface, not a few layers inside.

[rbjtech 5284]

41 minutes ago, Q-Droid said:

Which is why Emby is not the app to handle this as it doesn't control the network interface. For Emby to handle this a connection has to be attempted and established and already too deep inside your network, too late. The barrier ought to be the first line of defense and at or closest to the WAN interface, not a few layers inside.

Agreed, but you do need Emby to be able to comminicate to this perimeter defense to block/drop that IP.    As no doubt you are well aware, you also don't want your perimeter/dmz devices being able to initiate connection to inner layers (other way is obviously fine), thus you need emby to push the requests.     Currently I'm using Emby Scripter-X to write failed Auth to a file and this is then pushed via ssh to the dmz where it's picked up by fail2ban polling it, which then blocks the IP.   Messy and certainly not something I expect 'Emby' to accomodate out the box - but it would be nice within their own app framework to block IP's - as it's better than what they have now - especially as they have the functionality available to them (or do via the GUI anyway)..

[Q-Droid 989]

A way to send events to loggers, monitoring agents or management apps would be a good addition. I'm not convinced when it comes to blocking. Core media dev and support is stretched thin and taking on traffic management is out of scope in my view. I can think of a scenario where VPN exit points are blocked by Emby then valid VPN users get blocked as well. Sophisticated admins would understand the event and have external tools to handle it. Basic blocking in Emby with typical admins would not, needing support and then complain that it's not doing enough. 

[rbjtech 5284]

1 hour ago, Q-Droid said:

A way to send events to loggers, monitoring agents or management apps would be a good addition. I'm not convinced when it comes to blocking. Core media dev and support is stretched thin and taking on traffic management is out of scope in my view. I can think of a scenario where VPN exit points are blocked by Emby then valid VPN users get blocked as well. Sophisticated admins would understand the event and have external tools to handle it. Basic blocking in Emby with typical admins would not, needing support and then complain that it's not doing enough. 

Fair points - then Emby need to 'do it' or 'not do it' - half a solution raises more problems then it solves.   In this thread, emby is alerting the fact a brute force is being attempted with an unknown account - but if it cannot do anything about it, then maybe it shouldn't be alerting it at all or change the alert to a 'warn' in the log only, so those that want to do something about it can.

Yes syslog would be great ! 

[One2Go 120]

2 hours ago, Q-Droid said:

Your Emby server may not be the target, only the entry point because it's the path that's detectable by the intruder. The goal could very well be to enter and discover other paths into your network. Even if this one in particular only wants access to Emby you have to think big picture and protect the whole environment from the best vantage point.

Which is why Emby is not the app to handle this as it doesn't control the network interface. For Emby to handle this a connection has to be attempted and established and already too deep inside your network, too late. The barrier ought to be the first line of defense and at or closest to the WAN interface, not a few layers inside.

As you rightly say Emby may be the hole to get into my NAS. This was the case when QNAP released their Hybrid backup app which had an exploitable vulnerability to get into the NAS and gain root access control. They fixed the the app later after the damage was done. I was spared the agony because I never installed the app but for the thousands of users that did, it was an expense reaching into the millions of dollars of bitcoins to get the master key to decrypt their files.

While I understand to have a secure perimeter that screens access is preferable, to implement that is beyond my ability and knowledge. Since Emby already flags failed logins, certainly they are able to flag a failed login attempt because the user doesn't exist. It surely is possible to enter that into the logs and at the same time provide no response to the bad actor. Will that not result in them moving on to the next victim?

Spin this further. What if now the bad actor starts using common names like Peter or Jack which do not exist certainly no response should be provided. Why give the bad actor an answer to his inquiries? Not many of Emby users have the know how or detailed knowledge on how to secure your network from attacks.

This morning there were 5 attempts on trying to login with admin from Hong Kong. With the massive amount of breaches of security at huge companies and the data now being available on the dark web these scenarios of attempted attacks will only increase.

[ebr 16169]

18 hours ago, One2Go said:

when there is a login attempt with a user name that doesn't exist, than provide no feedback to the bad actor and "simply drop the connection, like a firewall would". I don't know how feasible that implementation is though.

Just because the user name is wrong doesn't automatically mean it is a "bad actor".  Perhaps after several attempts (still an assumption but a better one).

[One2Go 120]

2 minutes ago, ebr said:

Just because the user name is wrong doesn't automatically mean it is a "bad actor".  Perhaps after several attempts (still an assumption but a better one).

Don't most owners of Emby servers personally know the people they give access to? So if there is no feedback and they think they entered the correct credentials, than I get a call or an email asking what the problem is. When I am logging into sites and I get the credentials wrong some sites tell me something that indicates "wrong user or password" others just clear the fields and still others do nothing. In other words you either have the correct credentials or you don't. If you do not have the correct credentials you are in the group of individuals wanting to gain illegally access. That even applies to mistyped credentials. If the user knows the admin of the server it is easily resolved.

I have the cell/mobile number of every user that has access to my Emby server, accidental problems are easily solved. I am thoroughly convinced that what is being discussed in this thread deserves attention and some implementation in a future release.

[roaku 842]

1 hour ago, rbjtech said:

Fair points - then Emby need to 'do it' or 'not do it' - half a solution raises more problems then it solves.   In this thread, emby is alerting the fact a brute force is being attempted with an unknown account - but if it cannot do anything about it, then maybe it shouldn't be alerting it at all or change the alert to a 'warn' in the log only, so those that want to do something about it can.

Yes syslog would be great ! 

My opinion continues to be:

 

[ebr 16169]

2 hours ago, One2Go said:

Don't most owners of Emby servers personally know the people they give access to? So if there is no feedback and they think they entered the correct credentials, than I get a call or an email asking what the problem is. When I am logging into sites and I get the credentials wrong some sites tell me something that indicates "wrong user or password" others just clear the fields and still others do nothing. In other words you either have the correct credentials or you don't. If you do not have the correct credentials you are in the group of individuals wanting to gain illegally access. That even applies to mistyped credentials. If the user knows the admin of the server it is easily resolved.

I have the cell/mobile number of every user that has access to my Emby server, accidental problems are easily solved. I am thoroughly convinced that what is being discussed in this thread deserves attention and some implementation in a future release.

Okay, but I don't see how that changes the fact that someone mistyping their user name is not always a "bad actor" so, I wouldn't want the server to make that assumption until, maybe, it  happened several times.

[One2Go 120]

47 minutes ago, ebr said:

Okay, but I don't see how that changes the fact that someone mistyping their user name is not always a "bad actor" so, I wouldn't want the server to make that assumption until, maybe, it  happened several times.

It is my understanding that failed login attempts are handled in different ways. If a person tries to login with a non existing user account, Emby just logs it and posts it in the Alert section and also gives a reply. That includes "bad actors" and legitimate users that entered their user name wrong. No distinction needs to be made just handle them the same way, do not send a response or a reply, let the user guess what just happened. If there is no wood the fire will eventually go out.

If there are several identical attempt, I let the Devs decide how to handle that. At present when a valid user name was fund and now a brute force to guess the password is under way, only than after 10 attempts will Emby block logins. How long will the blocking last, 24 hours or less?

It would be nice to use the blacklist feature in Emby for failed non existing user attempt as well as brute force attacks on guessing legitimate users passwords.

Bottom line: I don't want to take the chance that Emby possibly could be the Trojan horse that opens up my QNAP NAS. The bleepingcomputer.com reported that something similar happened in April 2021 in the article they reported that a "Massive Qlocker ransomware attack uses 7zip to encrypt QNAP devices" it was made possible because of QNAP's terrible software and new apps that were installed with the latest QTS update. I read and wept about the agony that 484 comments brought to light.

[rbjtech 5284]

1 hour ago, ebr said:

Okay, but I don't see how that changes the fact that someone mistyping their user name is not always a "bad actor" so, I wouldn't want the server to make that assumption until, maybe, it  happened several times.

I think that is exactly what is being said ..  reply by all means that this is a bad username or password (don't say which), but after 10 tries,  issue the same message that the account has been locked for a peroid (ie give nothing away) - and then do not reply to any futher queries for that peroid.   Brute force is about slowing automated tries - so a 10 minute gap moving to a 30 minute gap after round 2 etc is more than enough for the bots to find an easier target ..  

[rbjtech 5284]

4 minutes ago, One2Go said:

It is my understanding that failed login attempts are handled in different ways. If a person tries to login with a non existing user account, Emby just logs it and posts it in the Alert section and also gives a reply. That includes "bad actors" and legitimate users that entered their user name wrong. No distinction needs to be made just handle them the same way, do not send a response or a reply, let the user guess what just happened. If there is no wood the fire will eventually go out.

If there are several identical attempt, I let the Devs decide how to handle that. At present when a valid user name was fund and now a brute force to guess the password is under way, only than after 10 attempts will Emby block logins. How long will the blocking last, 24 hours or less?

It would be nice to use the blacklist feature in Emby for failed non existing user attempt as well as brute force attacks on guessing legitimate users passwords.

We said the same thing ..

[One2Go 120]

37 minutes ago, rbjtech said:

We said the same thing ..

Any idea how long the blocking will last after 10 failed attempts to guess the password?

[ZanderKeen 72]

I do what @rbjtechmentioned and geo block all the countries except my own which reduced a majority of sus DNS hits. I also run fail2ban which talks to the reverse proxi and handles the bans when geo block doesn't help. My fail2ban allows far less failed password attempts than emby. I didn't realize emby had that security measure in place yet. When did that happen?

[dexus 27]

I'm with @rbjtechon changing the functionality of the lockout feature to include unknown user id's.  It seems like a simple modification, and even if it's not a perfect solution or a network layer hindrance, it will most of the time cause the attacking bot or persons to move on to another target, solving the immediate issue.  not all the time, but most, and that is a far cry better than none of the times..

As long as a bot gets the auth failed message back, it will continue trying for a long time, if blocked, or getting no response at all after 10 tries, it will move on..

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..