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 2078]

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

[Neminem 1984]

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 80]

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 43549]

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 57]

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 October 21 by Suliamu

[ebr 17032]

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 142]

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 76]

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 October 21 by js28194

[Suliamu 57]

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 142]

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 2078]

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 120]

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 43549]

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 2078]

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.

[jeanlucpicard 24]

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 October 22 by turpentine

[heffeque 120]

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 57]

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 120]

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. 

[jeanlucpicard 24]

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 ?

 

 

 

 

 

[jeanlucpicard 24]

12 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. even if you do not a known dns, because it is mathematicaly easier to scan. 

You are making fun of me because I am a foreigner and I don't speak English well." so i will continue to speak as i can
 

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.

the good news is the only person that know your full qualified domain name, this is you, or the persons you know, and the cloudflare guys. not just a random guy on earth, that scan the new registered domain names.

 

since ipv6, i have banned all ipv4, i have no script kiddies that are trying, to logon and test username/passwords.

and if someone my ip address because i have done an outgoing connection from the emby server to some untrusted web site, that collects source ip addresses, i quickly change the ipv6 suffix. since i am alive, i never had to do that.

the only error you can do is to AAAA record in an another dns registrar with no proxy mode, that point to your macadress ipv6 physical address. if you have attacks on this address, the only way to get red of that, is to have a good firewall or change your networking card. and then you will publish only a randomised ipv6 and not the one based on your mac address. 

 

 

Proxy status · Cloudflare DNS docs

 

 

Improved English Version (my explanation changed by IA)

"If there's a known DNS record, how does IPv6 help? The DNS points directly to the correct IPv6 address anyway, so am I missing something?

 

Actually, you don't have to create a DNS record for your IPv6 address. You can just enter the IPv6 address directly into your Emby clients. That way, nobody can find or scan you. In contrast, with IPv4, attackers will find you even without a known DNS record because the IPv4 address space is small enough to be easily scanned.

If you do want to use a URL (like yoursite.com) to connect to your server, you should use a Cloudflare DNS record in proxy mode. For example, you can create a Fully Qualified Domain Name (FQDN) like myrandomname.mydomain.com.

Only you and the friends you share it with will know this specific URL.

When someone performs a DNS lookup on your FQDN, Cloudflare replaces your real IPv6 address with a Cloudflare IPv6 address. This hides your origin IP. Furthermore, Cloudflare does not publicly list your proxied DNS records.
For instance, let’s say your Emby hostname is ilovetocriticize.acme.org. In the Cloudflare dashboard, you would create a AAAA record for ilovetocriticize.acme.org pointing to 2001:4860:482c:7700:04bf:7c04:d308:de3e. By default, Cloudflare suggests publishing this in 'DNS-only' mode. You shouldn't do that, because it exposes your real IPv6 address to every DNS server on earth.
Instead, enable proxy mode (the orange cloud). Cloudflare will mask your real IP with their own, and they will never expose your backend server's name under the acme.org domain. If anyone queries ilovetocriticize.acme.org, the DNS server will only return Cloudflare's proxy IPv6 address. The beauty of this setup is that the only people who know your FQDN are you, your trusted users, and Cloudflare—not a random attacker scanning newly registered domains.
Since switching to IPv6 and blocking all IPv4 traffic, I haven't seen a single script kiddie attempting brute-force logins on my server. Even if someone managed to harvest my source IP from an outgoing connection made by the Emby server to an untrusted website, I could easily rotate my IPv6 suffix. Fortunately, I’ve never even had to do that.
The only major mistake you can make is creating a AAAA record with a non-proxied provider that points to your static SLAAC IPv6 address (which is based on your physical MAC address). If that specific address gets targeted, your only options are a solid firewall or changing your network card. To avoid this, you should always configure your system to generate randomized public Pv6 addresses instead of MAC-based ones."  (static public prefix /56 /64, random suffix)

 

I asked claude to translate my english to better english, and please do not say i am bot 

 

 

 

 

 

 

 

Edited October 22 by turpentine

[jeanlucpicard 24]

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

i use this configuration before chat gpt exists, i just asked IA to correct my poor english. i use only ipv6 now for 4 years, my ipv6 address is random and fixed. no ssl leaks , no dns leaks. my ipv6 firewall is sleeping, no attacks, ipv6 saved my life