Jump to content

In regards to the recent vulnerability


Go to solution Solved by Luke,

Recommended Posts

Posted
1 minute ago, mcalbert007 said:

thanks for the replies guys, so this is now what i have done...

have deleted my 8096 from the router port forwarding, have changed the external port to another port and left the internal port as 8920

in the emby dashboard network settings i have turned them back to the defaults 8096 & 8920

i hope this is now correct and thanks again for the replies and the help.

To my understanding that is correct!

  • Thanks 1
darkassassin07
Posted (edited)

@mcalbert007

The only thing you may have missed is in emby>network 'public https port number' should match the public (external) port you've chosen in the router.

 

This tells the apps like emby for android how to reach you from outside your lan.

Edited by darkassassin07
  • Thanks 1
mcalbert007
Posted

ok thanks for keeping me right,
i have now made the public https port number the same as my external router port
hopefully this is the end to my attacks guys,
again thanks a bunch for the help

  • Like 1
  • 1 month later...
Posted

I had these attacks back in May, changed my ports and the attacks stopped. But now they're back again. Hoping for some additional clarification on the port forwarding to make sure I have things set correctly. Here's my takeaway from the prior responses:

Emby local settings (can stay default):

  • Local http 8096
  • Local https 8920

Emby public settings:

  • Public http: This can be the default or custom. Based on @darkassassin07it sounds like we should not forward this port through the router due to security concerns, but I may be misinterpreting. This cannot be left blank in Emby settings.
  • Public https: This can be default or custom (8999 for this example) and should be forwarded via router settings.

Router:

  • Forward the public port set in Emby's public https setting (8999 in this example) to local port 8999.

My problem is that with these settings I am unable to connect from outside my network. Have I got this all wrong or does this setup require an SSL certificate be installed or some other setting configured. TIA for the help, not sure why I'm still struggling with this.

pwhodges
Posted (edited)

You must have a certificate to enable https.  Until you have that, you need to allow http through the router to get access from outside your network.  Although being able to use https is best practice, using http in this context is probably less of a deal than you seem to think.

Http may also have its place in a secure system.  If you use Caddy as a reverse proxy, it will automatically get you a certificate, and will redirect any access on the http port to the https port; however, the http port can't be closed, because it is used in the default handshake to get or renew a certificate automatically.  (edit: this used to be true but is no longer so.)

Paul

Edited by pwhodges
justinrh
Posted
3 hours ago, pwhodges said:

the http port can't be closed, because it is used in the default handshake to get or renew a certificate automatically.

Are you sure this is still true for Caddy?  The only port I have open is 443.

pwhodges
Posted

Thanks for the heads-up - this has changed (I don't know when).

It's always been possible to remove the port 80 requirement by specifying a DNS challenge, but that requires including the plugin for your registrar when you download/build Caddy, and configuration in the caddyfile. 

But the default challenge was previously only the HTTP challenge, which requires port 80; however, now there is an alternative, the TLS-ALPN challenge, which doesn't need port 80.  Caddy tries all these challenges, initially at random, but learns if one of them is less successful than the other(s).  There is still text in some places in Caddy's documentation suggesting that port 80 is required if you don't use a DNS challenge.  (Details here.)

None the less, I think I will keep port 80 open, because that enables Caddy to redirect to port 443 and HTTPS, which is friendlier than just ignoring non-HTTPS connections.

Paul

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...