Is this a hacking attempt?

[SanguineWren 7]

In the past two days I've been seeing these failed logins - always spammed (all in the same minute) when I check my server activity logs. 

 

To my knowledge, I do not have any usernames like this in either Emby (unless they are built-in/hidden?) nor do I have them on my Synology.

 

Is there anything I can / should do about this?

[yocker 2045]

One of them is an attempt with the user "root" so highly likely.

[Neminem 1957]

I have see this in the past.

Script kiddy's scanning the internet looking to get access to Emby ports.

Jellyfin uses the same port as Emby, fyi.

Have not seen this since I setup a reverse proxy + Geo-blocking in my Unify network.

I would advice disabling the port forwarding for a couple of days, just to see if they give up and move on.

 

[MediaIntelNUC 71]

23 minutes ago, Neminem said:

I have Have not seen this since I setup a reverse proxy

 

Same here, happened a couple of times to me, but after shaping it up with NO-IP reverse proxy it havent happened since.

1 hour ago, SanguineWren said:

Is there anything I can / should do about this?

Get a reverse proxy to secure it up was my goto.

There are tutorials on this forum and on the web.

Best of luck!

/N

[Luke 43400]

Another good way to make your server harder to discover is to use router port numbers that are different from the default values. 

[Uncle_Frank 18]

On 10/16/2026 at 7:30 PM, Luke said:

Another good way to make your server harder to discover is to use router port numbers that are different from the default values. 

If I'm looking for Emby Servers that makes no difference NONE. If I'm running a port scan for Emby the port makes no difference at all I can target Emby and no matter the port I still will get the prompt no matter what port you change to.

[Suliamu 56]

I agree with Uncle_Frank. 
Changing ports and hoping for the best is security by obscurity. 
I personally only allow specific IPs in my firewall to access emby from the Internet. 
Nowadays they change rarely enough to make this manageable for couple clients of friends and family. 
Even better would be to use a battle-hardened VPN-System like OpenVPN or Wireguard, but this plays not well with certain clients, i understand that. 
Today with those AI-agents that try and error a service on the net with all available methods that can be operated also by so called "script kiddies" i wouldn't take my chance. 

Edit: I just wanted to add that especially Mediaservers are a high value target for "hackers" because those machines often have GPU-support (for transcoding). 
When "hackers" get access to those machines they can turn it directly into money. 

Edited yesterday at 11:55 AM by Suliamu

[ebr 16938]

2 minutes ago, Suliamu said:

Changing ports and hoping for the best is security by obscurity. 

The suggestion was just a small thing to stop some of the scanners.  It was not, by any means, a suggestion that it would secure anything.

[Symen_4ab 9]

Got the same list of attempts on the same day 

If you have decent enough passwords, this should not be a problem. Any internet-exposed service will get brute-force attempts, that's expected. Emby displays those attempts in big on the admin page, but many others just log them in a text file somewhere.

Also I'm on the team that thinks changing the port is not a bad idea. You will definitely avoid simple mass scanners. (I'd bet this one, with its 17 login tries with "root", "emby" and "123456", only scans the default port).

[Chillout 132]

Emby just needs a 10min autoban IP after so many failed attempts from the same address.  I think filezilla does that on their FTP server software.

 

[js28194 75]

I'm guessing most likely users are port forwarding at the router level 8096 to internal.  Which is fine as a step one to get remote access setup.  Step 2 would be putting it behind reverse proxy or other hardening techniquies.  Autoban for 10 mins is fine, but won't stop the overall hammering long term as they will come back after 10 mins or so.

I have another issue with another app that somehow has sussed out my address but the bots fail as they have no API Keys to login.  This is all OpenAI, Googlebot and Perplexity so nothing "nefarious" I suppose but annoying none the less.

IP's can also be banned banned at the router firewall level if you have those capabilities, but that also becomes a fruitless cat and mouse game long term.

Edited yesterday at 03:52 PM by js28194

[Suliamu 56]

2 hours ago, Chillout said:

Emby just needs a 10min autoban IP after so many failed attempts from the same address.

There is multiple ways around this. 
There is "rotating proxies" and often attackers have a big array of bots they command. 
Also when you allow ipv6 on your net then this won't work at all since ipv6-subnets were given away for free to people, there is a vast amount of them. You most likely also have a own subnet with thousands to millions of adresses through your provider. 

This all is fine to prevent someone bruteforcing the login-process, ok. 
But often exploits don't even need any user-access. 
And my worries are _not_ that someone can then access the normal emby-webinterface and browse my movies and watch Arielle, my worries are that someone 
manages to escalate into higher level access to the machine (at the OS-level!) through the emby-process so that he can run programs on that machine. 
 

[Chillout 132]

While users with advanced networking knowledge can secure their installations with tools like reverse proxies, most Emby users do not have the expertise to set that up.

It would be beneficial if the software included a few additional built-in security features beyond relying solely on strong passwords and hidden usernames.

 

[yocker 2045]

3 hours ago, Chillout said:

While users with advanced networking knowledge can secure their installations with tools like reverse proxies, most Emby users do not have the expertise to set that up.

It would be beneficial if the software included a few additional built-in security features beyond relying solely on strong passwords and hidden usernames.

 

Or a recommendation to reverse proxy programs.
It is relatively easy to set something like Caddy up.

[heffeque 112]

I also got the same login attempts around the same date as you.

I blocked all communications coming from that IP (a data center in the US).

Hopefully nothing comes out of it.

Question for Emby: can you put something up to auto-block IPs that have unsuccessfully tried to log in?

Cheers!

[Luke 43400]

25 minutes ago, heffeque said:

 

Question for Emby: can you put something up to auto-block IPs that have unsuccessfully tried to log in?

Cheers!

That's not currently built in, but it could be easily added.

[BalthazarBux 19]

I also got exactly that, from data center in US. Still a bit weird, have our logs some info in them maybe, if we have posted them here sometime?

[yocker 2045]

18 minutes ago, BalthazarBux said:

I also got exactly that, from data center in US. Still a bit weird, have our logs some info in them maybe, if we have posted them here sometime?

Probably some rented machine.

[turpentine 22]

Security Through Obscurity Isn't Enough

As a networking expert, changing default ports offers very little real protection. Even if you move a service to a non-standard port, an attacker can easily run an nmap scan across all ports. A full scan takes just a couple of hours, meaning they will quickly discover your new port anyway.

The core issue isn't your incoming TCP ports—it's that your server's public IP address is already exposed through public DNS records.

Two Effective Ways to Secure Your Server

1. Use a CDN Frontend (e.g., Cloudflare)

Routing your traffic through a free Cloudflare proxy completely hides your origin server's public IP address. Furthermore, Cloudflare's DNS proxy feature ensures that public DNS queries resolve to Cloudflare's edge servers rather than your actual infrastructure. If someone scans your domain name, your origin server is never listed, making it virtually impossible for scanners to find your true IP.

2. Leverage Full IPv6 with Randomized Suffixes

If you prefer not to use a CDN, migrating exclusively to IPv6 provides strong protection due to the sheer scale of the address space.

Massive Scanning Complexity: Brute-forcing or scanning an entire IPv6 subnet is computationally infeasible.

Randomized Suffixes: Ensure you configure your server to use random suffixes rather than addresses based on your hardware's MAC address (EUI-64).

An unknown, randomly generated IPv6 address that isn't published publicly is extremely difficult for an attacker to discover or target.

 

Pro Tip: Double Down for Maximum Paranoia! (private joke)

Of course, if you are feeling exceptionally cautious, you can simply combine both methods: put Cloudflare in front of a pure IPv6 server with randomized suffixes. At that point, a hacker has a significantly higher chance of winning the lottery, getting struck by lightning, and finding a needle in a haystack all on the same day than actually discovering your origin IP address. If they somehow still manage to attack you, you should probably just congratulate them on defying the laws of mathematics!

Would you like help configuring Cloudflare proxy settings, or would you prefer to explore setting up randomized IPv6 suffixes for your server?

it is very difficult for a hacker to guess an ipv6 address which is not publicly known

 

i agree with chillout, an basic 10 min fail2ban feature like would be cool, desactivated by default. the user can activate it. it is better to have a basic but somehow reliable basic security feature. everyone is not experts in everything. you can be good at networking, but bad in software understanding. 

my preference goes anyway to ipv6

 

Edited 17 hours ago by turpentine

[heffeque 112]

If there's a known DNS... How does IPv6 help? The DNS points towards the correct IPv6 address, so...

Or am I missing something? 

[Suliamu 56]

12 hours ago, turpentine said:

Security Through Obscurity Isn't Enough

As a networking expert, changing default ports offers very little real protection. Even if you move a service to a non-standard port, an attacker can easily run an nmap scan across all ports. A full scan takes just a couple of hours, meaning they will quickly discover your new port anyway.

The core issue isn't your incoming TCP ports—it's that your server's public IP address is already exposed through public DNS records.

Two Effective Ways to Secure Your Server

1. Use a CDN Frontend (e.g., Cloudflare)

Routing your traffic through a free Cloudflare proxy completely hides your origin server's public IP address. Furthermore, Cloudflare's DNS proxy feature ensures that public DNS queries resolve to Cloudflare's edge servers rather than your actual infrastructure. If someone scans your domain name, your origin server is never listed, making it virtually impossible for scanners to find your true IP.

2. Leverage Full IPv6 with Randomized Suffixes

If you prefer not to use a CDN, migrating exclusively to IPv6 provides strong protection due to the sheer scale of the address space.

Massive Scanning Complexity: Brute-forcing or scanning an entire IPv6 subnet is computationally infeasible.

Randomized Suffixes: Ensure you configure your server to use random suffixes rather than addresses based on your hardware's MAC address (EUI-64).

An unknown, randomly generated IPv6 address that isn't published publicly is extremely difficult for an attacker to discover or target.

 

Pro Tip: Double Down for Maximum Paranoia! (private joke)

Of course, if you are feeling exceptionally cautious, you can simply combine both methods: put Cloudflare in front of a pure IPv6 server with randomized suffixes. At that point, a hacker has a significantly higher chance of winning the lottery, getting struck by lightning, and finding a needle in a haystack all on the same day than actually discovering your origin IP address. If they somehow still manage to attack you, you should probably just congratulate them on defying the laws of mathematics!

Would you like help configuring Cloudflare proxy settings, or would you prefer to explore setting up randomized IPv6 suffixes for your server?

it is very difficult for a hacker to guess an ipv6 address which is not publicly known

 

i agree with chillout, an basic 10 min fail2ban feature like would be cool, desactivated by default. the user can activate it. it is better to have a basic but somehow reliable basic security feature. everyone is not experts in everything. you can be good at networking, but bad in software understanding. 

my preference goes anyway to ipv6

 

Sir, this text is written by a very, very bad LLM. 
Everything there is completely wrong. 
If you do what this says you will make your system even more insecure. 
 

[heffeque 112]

1 minute ago, Suliamu said:

Sir, this text is written by a very, very bad LLM. 
Everything there is completely wrong. 
If you do what this says you will make your system even more insecure. 
 

It looked like AI slop. The IPv6 inconsistency stood out the most for me. 

[turpentine 22]

4 hours ago, heffeque said:

It looked like AI slop. The IPv6 inconsistency stood out the most for me. 

 I often use AI to rephrase my English because it’s not my native language. I’m curious to know what was incorrect in what I said.

since i am on ipv6, i have no scans on my ipv6 address.

it is easy to criticize, but what do you propose instead ?

 

 

 

 

 

[turpentine 22]

10 hours ago, heffeque said:

If there's a known DNS... How does IPv6 help? The DNS points towards the correct IPv6 address, so...

Or am I missing something? 

There is no law that requires you to create a DNS record pointing to your IPv6 address. you put directly the ipv6 address directly in your emby clients. no one will find you, or scan you.

in ipv4 they will find you.

if you want to yoursite.com address to connect your server with an url, you use the cloudflare dns record in proxy mode, like  myrandomname.mydomain.com which is your full qualified domain name.  you will be the only one to know your full qualified domain name, or the friends that will connect to it , will know the url of your server.

when you will do a dnslookup of your FQDN , the cloudflare dns servers will replace your ipv6 by cloudflare ipv6. no one will find you either. moreover in proxy mode dns records will never be listed by cloudflare, in proxy mode

for exemple let say your emby host name is      ilovetocriticize.acme.org

in the cloudflare user interface you will do a AAAA Record for ilovetocriticize.acme.org and it points to 2001:4860:482c:7700:04bf:7c04:d308:de3e

by default, it will propose to add the record and publish it dns mode, you should not do that, because it will tell everyone your real ipv6 address to all the dns servers on earth.

 

instead you add this record in proxy mode. and here cloudflare will replace your ipv6 by their ipv6 and cloudflare will never list your ilovetocriticize server for domain name acme.org.  but if someone does a request dns query to ilovetocriticize.acme.org, the dns server will respond by their proxy ipv6 address.

 

 

Proxy status · Cloudflare DNS docs

 

Edited 10 minutes ago by turpentine