[TUTO] Configurer un reverse proxy pour Emby, sur Ubuntu

[Randdrick 24]

Bonjour,
Pour celles et ceux qui ont un serveur Emby sous Ubuntu et veulent sécuriser leur connexion grâce à un reverse proxy, voici la démarche à suivre.
Même si un reverse proxy est un serveur indépendant, servant à sécuriser les serveur web des requêtes malveillantes, l'avantage de le créer sur votre serveur Emby vous permettra de laisser ouvert en entrée, sur votre pare-feu, uniquement les port 80 et 443. Le port 8096 pourra rester fermé. De plus, les communications entre vos client et votre serveur seront encryptées.

Installation d'Apache
Apache est le serveur Web le plus utilisé au monde. il doit être installé au préalable pour permettre faire fonctionner le reverse proxy.
Pour se faire, vous devez l'installer en tant qu'utilisateur non-root.

On commence par mettre à jour les paquets :

sudo apt update

Puis on installe Apache

sudo apt install apache2

À la fin du processus d’installation, Ubuntu démarre Apache. Le serveur Web doit déjà être opérationnel.
Vérifiez auprès du système d’init pour vous assurer que le service est en cours d’exécution en tapant :

sudo systemctl status apache2

Vous devez obtenir un résultat semblant à :

Quote

Output
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-04-23 22:36:30 UTC; 20h ago
       Docs: https://httpd.apache.org/docs/2.4/
   Main PID: 29435 (apache2)
      Tasks: 55 (limit: 1137)
     Memory: 8.0M
     CGroup: /system.slice/apache2.service
             ├─29435 /usr/sbin/apache2 -k start
             ├─29437 /usr/sbin/apache2 -k start
             └─29438 /usr/sbin/apache2 -k start

Afin d'éviter d'utiliser le fichier de configuration par défaut d'Apache, nous allons en créer un nouveau :

sudo nano /etc/apache2/sites-available/emby.conf

Recopier dans le fichier emby.conf, les lignes suivantes :

<VirtualHost *:80>
        ServerName mon.domain.com
        ServerAdmin youremail@address.com

	RewriteEngine on
	RewriteCond %{SERVER_NAME} =mon.domain.com
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>

Remplacer mon.domain.com par le nom de votre domaine (qui peut être aussi de type NoIp - Exemple : monserveuremby.ddns.net)
Remplacer youremail@adress.com par votre adresse mail (qui peut être aussi webmaster@localhost)

Enregistrez et fermez le fichier lorsque vous avez terminé.

Activons le fichier avec l’outil: a2ensite

sudo a2ensite emby.conf

Désactiver le site par défaut défini dans :000-default.conf

sudo a2dissite 000-default.conf

Ensuite, testons les erreurs de configuration:

sudo apache2ctl configtest

Vous devriez recevoir la sortie suivante :

Quote

Output
Syntax OK

Redémarrez Apache pour implémenter vos modifications :

sudo systemctl restart apache2

Installation du certificat de sécurité (Let's Encrypt)
Afin d'obtenir un certificat SSL avec Let’s Encrypt, nous devrons d’abord installer le logiciel Certbot sur votre serveur. Nous utiliserons les référentiels de paquets Ubuntu par défaut pour cela. Une seule commande suffit :

sudo apt install certbot python3-certbot-apache

Vous serez invité à confirmer l’installation.

Certbot est maintenant installé sur votre serveur. 

Obtention d’un certificat SSL
Certbot fournit une variété de façons d’obtenir des certificats SSL via des plugins. Le plugin Apache se chargera de reconfigurer Apache et de recharger la configuration chaque fois que nécessaire. Pour utiliser ce plugin, tapez ce qui suit :

sudo certbot --apache

Ce script vous invitera à répondre à une série de questions afin de configurer votre certificat SSL. Tout d’abord, il vous demandera une adresse e-mail valide. Cet e-mail sera utilisé pour les notifications de renouvellement et les avis de sécurité :

Quote

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): you@your_domain
 

Après avoir fourni une adresse e-mail valide, appuyez sur pour passer à l’étape suivante. Vous serez ensuite invité à confirmer si vous acceptez les conditions d’utilisation de Let’s Encrypt. Vous pouvez confirmer en appuyant sur la touche A et confirmer en appuyant sur la touche ENTER

Quote

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

Ensuite, il vous sera demandé si vous souhaitez partager votre courrier électronique avec l’Electronic Frontier Foundation pour recevoir des nouvelles et d’autres informations. Si vous ne souhaitez pas vous abonner à leur contenu, tapez N et confirmer en appuyant sur la touche ENTER

Quote

- - - - - - - - - - - - - - - - - - - - - - - -

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: your_domain
2: www.your_domain
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 

- - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

L’étape suivante vous invitera à informer Certbot des domaines pour lesquels vous souhaitez activer HTTPS. Les noms de domaine répertoriés sont automatiquement obtenus à partir de votre configuration d’hôte virtuel Apache, c’est pourquoi il est important de vous assurer que vous avez les paramètres corrects et configurés dans votre hôte virtuel. Si vous souhaitez activer HTTPS pour tous les noms de domaine répertoriés (recommandé), vous pouvez laisser l’invite vide et cliquer pour continuer.

Quote

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: your_domain
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 

Vous verrez une sortie comme celle-ci :

Quote

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for your_domain
Enabled Apache rewrite module
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/your_domain-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/your_domain-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf

Ensuite, vous serez invité à sélectionner si vous souhaitez ou non que le trafic HTTP soit redirigé vers HTTPS. En pratique, cela signifie que lorsque quelqu’un visite votre site Web via des canaux non cryptés (HTTP), il sera automatiquement redirigé vers l’adresse HTTPS de votre site Web. Choisissez 2 pour activer la redirection HTTP vers HTTPS

Quote

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

Après cette étape, la configuration de Certbot est terminée et les remarques finales sur votre nouveau certificat, où localiser les fichiers générés et comment tester votre configuration à l’aide d’un outil externe qui analyse l’authenticité de votre certificat seront affichées :

Quote

Congratulations! You have successfully enabled https://your_domain and
https://www.your_domain

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
https://www.ssllabs.com/ssltest/analyze.html?d=www.your_domain
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/your_domain/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/your_domain/privkey.pem
   Your cert will expire on 2020-07-27. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                   https://eff.org/donate-le

Vérification du renouvellement automatique de Certbot
Les certificats de Let’s Encrypt ne sont valides que pendant quatre-vingt-dix jours. Il s’agit d’encourager les utilisateurs à automatiser leur processus de renouvellement de certificat, ainsi que de s’assurer que les certificats mal utilisés ou les clés volées expireront le plus tôt possible.

Le paquet que nous avons installé prend en charge les renouvellements en incluant un script de renouvellement à , qui est géré par un service appelé . Ce script s’exécute deux fois par jour et renouvelle automatiquement tout certificat dans les trente jours suivant son expiration.

Pour vérifier l’état de ce service et vous assurer qu’il est actif et en cours d’exécution, tapez la commande suivante  :

sudo systemctl status certbot.timer

Vous obtiendrez une sortie similaire à celle-ci :

Quote

● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-04-28 17:57:48 UTC; 17h ago
    Trigger: Wed 2020-04-29 23:50:31 UTC; 12h left
   Triggers: ● certbot.service

Apr 28 17:57:48 fine-turtle systemd[1]: Started Run certbot twice daily.

Activation des modules Apache nécessaires pour le reverse proxy
Apache a de nombreux modules fournis avec lui qui sont disponibles mais pas activés dans une nouvelle installation. Tout d’abord, nous devrons activer ceux que nous utiliserons dans ce didacticiel.

Les modules dont nous avons besoin sont lui-même et plusieurs de ses modules complémentaires, qui étendent ses fonctionnalités pour prendre en charge différents protocoles réseau. Plus précisément, nous utiliserons :mod_proxy

mod_proxy, le module proxy principal Apache module pour la redirection des connexions; il permet à Apache d’agir comme une passerelle vers les serveurs d’applications sous-jacents.
mod_proxy_http, qui ajoute la prise en charge de la transmission par proxy des connexions HTTP.

Pour activer ces deux modules, exécutez successivement les commandes suivantes.

sudo a2enmod proxy
sudo a2enmod proxy_http

Pour mettre ces modifications en œuvre, redémarrez Apache.

sudo systemctl restart apache2

Configuration du reverse proxy pour Emby
La dernière étape consiste à configurer le reverse proxy pour emby. Pour cela, éditer avec nano, le fichier qui se trouve dans /etc/apache2/sites-available et devrait s'appeler (dans notre tuto) emby-le-ssl.conf

sudo nano /etc/apache2/sites-available/emby-le-ssl.conf

et modifiez le comme suit :

<IfModule mod_ssl.c>
<VirtualHost *:443>
	ServerName mon.domain.com
	ServerAdmin youremail@address.com

	<proxy *>
	AddDefaultCharset off
	Order Allow,Deny
	Allow from all
	</proxy>

	ProxyRequests     Off
	ProxyPreserveHost On

	ProxyPass "/embywebsocket" "ws://127.0.0.1:8096/embywebsocket"
	ProxyPassReverse "/embywebsocket" "ws://127.0.0.1:8096/embywebsocket"

	ProxyPass "/" "http://127.0.0.1:8096/"
	ProxyPassReverse "/" "http://127.0.0.1:8096/"

	SSLCertificateFile /etc/letsencrypt/live/mon.domain.com/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/mon.domain.com/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Remplacer mon.domain.com par le nom de votre domaine (qui peut être aussi de type NoIp - Exemple : monserveuremby.ddns.net)
Remplacer youremail@adress.com par votre adresse mail (qui peut être aussi webmaster@localhost)

Pour mettre ces modifications en œuvre, redémarrez Apache.

sudo systemctl restart apache2

Tester votre configuration et configurer un client Emby
Il vous suffit de taper mon.domain.com dans la barre de votre navigateur sans rajouter 8096. 
Pour configurer un client Emby (Android, Smart TV, etc.) il vous suffit juste de rentrer l'url en https de votre votre serveur (ex : https://mon.domain.com) et de laisser le champ port vide.

[Carlo 4331]

Great info, thanks so much for this.

Could a mod copy this to the Tutorials and Guides section and make sure it's in English?

[thymon 9]

t'es un chef !

Sachant que ça peu s'appliquer pour des tas d'autres chose.

Dès que l'on a besoin d'un reverse proxy + ssl

 

Bravo c'est très claire.

[badous 14]

@Randdrick Salut et un grand merci pour ce tuto. Il est vraiment détaillé. Je vais essayer de le suivre. Un peu de sécurité ne fait pas de mal.

Vraiment beau boulot.

[Randdrick 24]

Merci à tous pour vos réactions.
Une petite précision que j'apporte par rapport à mon Tuto, concernant les différents client Emby :

- Pour tous les clients Emby (Android, Apple, Android TV, Emby Theater, etc) sauf un navigateur, le port 8096 doit rester ouvert pour la première authentification d'un nouvel utilisateur. Il en va de même pour l'enrôlement du client par rapport au serveur. Ceci n'est pas dû à la configuration du reverse proxy, mais a un bug sur Emby (qui a déjà été remonté) par d'autres. Une fois l'utilisateur (ou le client enrôlé) le port 8096 peut être refermé au niveau du pare-feu.

- Concernant Emby Theater, le port 8096 doit tout le temps rester ouvert au niveau de votre pare-feu, sinon les vidéos ne se liront pas. Là encore, c'est un problème qui n'est pas lié au reverse proxy.

[Randdrick 24]

Ne pouvant modifier mon post précédent, j'apporte la précision suivante.

Vous devez comprendre (lorsque je parle du pare-feu) que je fais référence au pare-feu de votre box ou celui de votre hébergeur. 
Il est évident que les ports 80, 443, 8096 et éventuellement le 8920 (selon votre configuration) doivent rester ouverts sur votre serveur pour permettre son bon fonctionnement. 

Edited November 10, 2021 by Randdrick
Correction pour meilleur compréhension du post

[Luke 37248]

On 11/9/2021 at 5:22 PM, Randdrick said:

Merci à tous pour vos réactions.
Une petite précision que j'apporte par rapport à mon Tuto, concernant les différents client Emby :

- Pour tous les clients Emby (Android, Apple, Android TV, Emby Theater, etc) sauf un navigateur, le port 8096 doit rester ouvert pour la première authentification d'un nouvel utilisateur. Il en va de même pour l'enrôlement du client par rapport au serveur. Ceci n'est pas dû à la configuration du reverse proxy, mais a un bug sur Emby (qui a déjà été remonté) par d'autres. Une fois l'utilisateur (ou le client enrôlé) le port 8096 peut être refermé au niveau du pare-feu.

- Concernant Emby Theater, le port 8096 doit tout le temps rester ouvert au niveau de votre pare-feu, sinon les vidéos ne se liront pas. Là encore, c'est un problème qui n'est pas lié au reverse proxy.

HI @Randdrick what bug are you referring to that has been reported? The Emby Theater app will use the correct port. It's not hard-coded to 8096.

[Randdrick 24]

Hi @Luke,
I refer to his post : 

I confirm, when you have a reverse proxy, you may  keep open port 8096 open on your firewall.

For exemple :
I've a public firewall with port's 80, 443, 22 open only.  I've a VPS server on witch my emby server and my reverse proxy are installed.  All inbound ports are open on this. My VPS server is behind my public firewall.
My reverse proxy make a secure port redirection 80 to 8096
If port 8096 isn't open on my public firewall, I can acces to my Emby server but i can't connect on my server  with an Emby client (Android, Apple, Android TV, Emby Theater, etc), an user who has never authenticated. Error message : User or password is invalid.
if port 8096 isn't open on my public firewall, I can connect on my server with an existing user who has already authenticated at least once , but I can't play my vidéos on Emby Theater. I don't know why. With another Emby client, it's work.
If I keep open port 8096 on my public firewall, I can connect new user on any Emby client and play my videos fine.

Edited November 12, 2021 by Randdrick

[Mickelebof 16]

Hello,

Pour info, j'utilise également un reverse proxy (avec Nginx et non Apache) et je n'ai pas le problème que tu mentionnes sur le port 8096 à laisser ouvert sur le firewall (le miens est donc fermé).
J'ai bon nombre d'utilisateurs qui l'utilisent sans problème avec divers clients, dont Emby Theater.

Cordialement,
Mick

Edit : Je viens de lire ton post sur la remonté du problème (j'aurais du le faire avant lol) et la différence c'est que mes contenus ne sont pas sur un serveur externe, effectivement

Edited November 14, 2021 by Mickelebof

[neves000 15]

Bonjour,

Merci pour ce tuto très détaillé !

Je passe peut être à coté de quelque chose, mais je ne vois pas l’intérêt d'un reverse proxy ici. Dans le tutorial, on "ProxyPass" tout ce qui arrive sur le port 433 en SSL vers le port 8096 d'Emby. Pourquoi ne pas directement rediriger le port 443 (ou un autre port pour plus de discrétion) sur la box vers le port 8096 d'Emby et utiliser la gestion SSL intégrée à Emby ? J'imagine qu'en plus avec le reverse proxy, on ne peut plus utiliser la fonction "filtre d'adresse IP distante" puisqu'Emby doit voir tous les utilisateurs avec l'adresse IP du reverse proxy.

J'ai loupé quelque chose ? Merci !

 

[Mickelebof 16]

Hello,

Pour ma part, j'ai plusieurs sites/applications derrières ma box.
Si je redirige le port 443 sur Emby, je ne peux plus utiliser ce port (standard) pour mes autres sites.
Autre avantage, tu peux gérer le renouvellement de ton (tes) certificat Let's Encrypt en automatique sur le Reverse Proxy et de manière transparente.

Pour ce qui est du filtrage par IP, tu peux tout à fait continuer à le faire, il suffit de demander au reverse proxy de forward les IP des clients vers Emby.
Pour ma part sur Nginx, il faut rajouter :

    proxy_set_header      X-Real-IP $remote_addr;
    proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;

Je n'ai pas fait d'Apache depuis longtemps, je laisse ceux qui connaissent donner l’équivalent pour Apache

Mick
~                                                                           

Edited November 14, 2021 by Mickelebof

[neves000 15]

Ok, en effet, je comprend l’intérêt quand on a plusieurs services sur le port 443. Mais je suis d'avis d'expliquer cela dans le tutorial ; pour l'instant on a l'impression que mettre en place le reverse proxy c'est pour sécuriser Emby, alors que ça n'apporte rien en terme de sécurité.

Concernant le renouvellement du certificat SSL, j'aimerais bien qu'Emby ajoute un support natif de Let's Encrypt

Au sujet du filtrage IP, oui bien sûr on peut le faire au niveau du reverse proxy, voire même au niveau de la box (dans mon cas j'ai une redirection sur mon routeur d'un port haut vers le port 8096 d'Emby avec une liste d'IP autorisées au niveau du firewall du routeur). Mais ce que je voulais dire c'est que dans l'état actuel du tutorial, des personnes peuvent mettre en place le reverse proxy en ayant déjà un filtrage d'IP interdites sur Emby, le rendant ainsi inopérant sans qu'elles ne s'en rendent compte.

Avec ton ajout de conf nginx, c'est bon mais seulement si Emby prend un compte les headers ajoutés par le reverse proxy (à vérifier !)

Edited November 14, 2021 by neves000

[Lenders57 15]

On 11/12/2021 at 7:41 PM, Randdrick said:

Hi @Luke,
I refer to his post : 

I confirm, when you have a reverse proxy, you may  keep open port 8096 open on your firewall.

For exemple :
I've a public firewall with port's 80, 443, 22 open only.  I've a VPS server on witch my emby server and my reverse proxy are installed.  All inbound ports are open on this. My VPS server is behind my public firewall.
My reverse proxy make a secure port redirection 80 to 8096
If port 8096 isn't open on my public firewall, I can acces to my Emby server but i can't connect on my server  with an Emby client (Android, Apple, Android TV, Emby Theater, etc), an user who has never authenticated. Error message : User or password is invalid.
if port 8096 isn't open on my public firewall, I can connect on my server with an existing user who has already authenticated at least once , but I can't play my vidéos on Emby Theater. I don't know why. With another Emby client, it's work.
If I keep open port 8096 on my public firewall, I can connect new user on any Emby client and play my videos fine.

J'ai aussi un reverse proxy mais avec nginx et pas de 8096, strange

Edited November 14, 2021 by Lenders57

[Randdrick 24]

1 hour ago, neves000 said:

Au sujet du filtrage IP, oui bien sûr on peut le faire au niveau du reverse proxy, voire même au niveau de la box (dans mon cas j'ai une redirection sur mon routeur d'un port haut vers le port 8096 d'Emby avec une liste d'IP autorisées au niveau du firewall du routeur). Mais ce que je voulais dire c'est que dans l'état actuel du tutorial, des personnes peuvent mettre en place le reverse proxy en ayant déjà un filtrage d'IP interdites sur Emby, le rendant ainsi inopérant sans qu'elles ne s'en rendent compte.

En fait, si tu sécurises Emby, puisque qu'avec une redirection Proxy en SSL tu encryptes tes communications. Ton Url sera réécrite sous cette forme :
https://monembyserver.ddns.net et non http://monembyserver.ddns.net:8096

De plus, tes utilisateurs pour directement taper dans leur navigateur, par exemple, monembyserver.ddns.net sans se soucier du port qu'ils vont interroger.

Là, j'ai un serveur Emby public. Mais je pourrais avoir aussi un serveur Apache public, derrière un firewall public (sur lequel j'aurais activé la fonctionnalité de Load Balancing) , qui fait du reverse proxy pour plusieurs serveur Emby public. L'avantage d'une telle configuration, c'est que ton serveur Apache est le seul a être interrogé par les utilisateurs. Il se charge, après, de communiquer avec ton/tes serveurs Emby. Ainsi, ton serveur Emby n'est jamais directement exposé en frontale ce qui implique que si il y a une attaque, l'attaque se fera sur ton serveur Apache et non pas sur ton serveur Emby. Mais bon, faut pas pousser non plus. 

Dans le cas d'un simple serveur Emby, derrière ta box, cela apporte quand même en terme de sécurité car le principe de fonctionnement est le même si tu ouvres ton serveur en accès distant à d'autres utilisateurs. Il te suffira juste d'ouvrir le port 80 en entrée vers ton serveur Emby, ton reverse proxy sera chargera de  rediriger ton flux ver le port 8096 et l'encryptera.

Si ton serveur Emby ne te sert que pour toi, en local, en effet un reverse proxy ne sert absolument à rien.

2 hours ago, Mickelebof said:

Pour info, j'utilise également un reverse proxy (avec Nginx et non Apache) et je n'ai pas le problème que tu mentionnes sur le port 8096 à laisser ouvert sur le firewall (le miens est donc fermé).
J'ai bon nombre d'utilisateurs qui l'utilisent sans problème avec divers clients, dont Emby Theater.

En fait, oui c'est ainsi que cela devrait fonctionner. Je n'explique pas pourquoi le port 8096 doit rester ouvert sur le firewall pour que Emby Theater fonctionne. Et même dans le cas d'un VPS, cela n'a pas de sens. Peut-être est-ce dû à Apache, mais cela n'a pas de sens non plus.
 

51 minutes ago, Lenders57 said:

J'ai aussi un reverse proxy mais avec nginx et pas de 8096, strange

Ce qui est d'autant plus étonnant, c'est que si tu as créé un utilisateur, que tu t'es connecté au moins une fois avec son compte, ca fonctionnera sans problème (Sauf pour Emby Theater qui a ce problème de lecture.)
De plus, il n'y a aucun soucis pour les clients qui utilisent un navigateur web quel qu'il soit.

[Mickelebof 16]

@Randdrick as-tu la possibilité d'essayer avec Nginx ? Juste histoire d'écarter la possibilité que ça vienne d'Apache

Edit : Peut être un test à faire avant, as-tu essayé de rediriger vers le port 8920 au lieu du 8096 de ton Emby ?

En mettant ceci dans les paramètres réseau côté Emby :

Edited November 14, 2021 by Mickelebof

[Lenders57 15]

13 minutes ago, Randdrick said:

En fait, si tu sécurises Emby, puisque qu'avec une redirection Proxy en SSL tu encryptes tes communications. Ton Url sera réécrite sous cette forme :
https://monembyserver.ddns.net et non http://monembyserver.ddns.net:8096

De plus, tes utilisateurs pour directement taper dans leur navigateur, par exemple, monembyserver.ddns.net sans se soucier du port qu'ils vont interroger.

Là, j'ai un serveur Emby public. Mais je pourrais avoir aussi un serveur Apache public, derrière un firewall public (sur lequel j'aurais activé la fonctionnalité de Load Balancing) , qui fait du reverse proxy pour plusieurs serveur Emby public. L'avantage d'une telle configuration, c'est que ton serveur Apache est le seul a être interrogé par les utilisateurs. Il se charge, après, de communiquer avec ton/tes serveurs Emby. Ainsi, ton serveur Emby n'est jamais directement exposé en frontale ce qui implique que si il y a une attaque, l'attaque se fera sur ton serveur Apache et non pas sur ton serveur Emby. Mais bon, faut pas pousser non plus. 

Dans le cas d'un simple serveur Emby, derrière ta box, cela apporte quand même en terme de sécurité car le principe de fonctionnement est le même si tu ouvres ton serveur en accès distant à d'autres utilisateurs. Il te suffira juste d'ouvrir le port 80 en entrée vers ton serveur Emby, ton reverse proxy sera chargera de  rediriger ton flux ver le port 8096 et l'encryptera.

Si ton serveur Emby ne te sert que pour toi, en local, en effet un reverse proxy ne sert absolument à rien.

En fait, oui c'est ainsi que cela devrait fonctionner. Je n'explique pas pourquoi le port 8096 doit rester ouvert sur le firewall pour que Emby Theater fonctionne. Et même dans le cas d'un VPS, cela n'a pas de sens. Peut-être est-ce dû à Apache, mais cela n'a pas de sens non plus.
 

Ce qui est d'autant plus étonnant, c'est que si tu as créé un utilisateur, que tu t'es connecté au moins une fois avec son compte, ca fonctionnera sans problème (Sauf pour Emby Theater qui a ce problème de lecture.)
De plus, il n'y a aucun soucis pour les clients qui utilisent un navigateur web quel qu'il soit.

 

Je viens de créer un utilisateur bidon, j'arrive à me connecter via 4g

J'ai réussi à me co également avec emby theater (sur mon pc du réseau local mais en mettant l'adresse de mon serveur publique contenant emby et non l'ip local) et ça fonctionne aussi, donc je comprends pas le bug . En revanche il m'est arrivé plusieurs fois (y'a quelques temps, j'ai plus le soucis) de me faire déco sur mon phone et en essayant de me reco impossible identifiants incorrects alors que j'avais pas d'alertes sur le dashboard.

Sinon pour répondre à @neves000 l'intérêt d'un reverse proxy est :

• D'avoir plusieurs applications / site publics (https) sur une même machine sans à avoir à spécifier le port comme dit @Randdrick
• Tu auras un nom de domaine associé (ou des sous domaines), plus besoin de retenir une suite de nombre (ton ip publique, qui elle, peut potentiellement changer si tu heberges chez toi avec une box orange par exemple)
• De limiter l'ouverture des ports, par exemple imagine tu as un site il tournera sur le port 80/443, emby non sécurisé : 8096, emby sécure xxxx, ça te fait 4 ports d'ouverts, donc 4 fois plus vulnérable
• Enfin, grâce au reverse proxy, tu peux également gérer ta conf serveur, par exemple, limiter la taille de téléchargement d'un fichier, la vitesse, mettre un fail2ban (bannir une ip si elle flood) etc etc

[neves000 15]

53 minutes ago, Randdrick said:

En fait, si tu sécurises Emby, puisque qu'avec une redirection Proxy en SSL tu encryptes tes communications. Ton Url sera réécrite sous cette forme :
https://monembyserver.ddns.net et non http://monembyserver.ddns.net:8096

Désolé d'insister, mais je ne suis pas d'accord avec la notion de sécurisation, avec le système mis en place dans le tutorial tel qu'il est actuellement :

• Emby sait déjà chiffrer la communication en SSL tout seul ;
• Dans le cas d'un forward de ports direct depuis le routeur vers un Emby SSL, on expose à un attaquant toute la surface d'Emby (ce qui est atteignable sur le port 8096)
• Dans le cas d'Emby derrière un reverse proxy, on expose encore à un attaquant toute la surface d'Emby à laquelle on ajoute celle du reverse proxy lui-même. Le reverse proxy seul ne va réaliser aucun filtrage sur ce qu'un attaquant va envoyer à Emby (Il faudrait ajouter un WAF). Alors je suis bien d'accord, c'est rare qu'on trouve des vulnérabilités dans nginx ou apache (même si on a eu droit à CVE-2021-41773 récemment), mais je suis partisan de l'option avec le moins de complexité possible.

53 minutes ago, Randdrick said:

De plus, tes utilisateurs pour directement taper dans leur navigateur, par exemple, monembyserver.ddns.net sans se soucier du port qu'ils vont interroger.

Ce n'est pas le reverse proxy qui permet cela mais l'utilisation du port 80 ou 443, que les navigateurs Web "connaissent". Personnellement, je préfère au contraire utiliser un port non commun pour ce genre de logiciel (on ne tape l'URL qu'à la première configuration du client, je trouve que ce n'est pas la mer à boire d'ajouter un port). Histoire que si un jour une vulnérabilité est trouvée dans Emby, tous les pirates qui scannent les ports 80/443 en permanence sur Internet ne sachent pas immédiatement où ils peuvent balancer leur cryptomineur.

53 minutes ago, Randdrick said:

Là, j'ai un serveur Emby public. Mais je pourrais avoir aussi un serveur Apache public, derrière un firewall public (sur lequel j'aurais activé la fonctionnalité de Load Balancing) , qui fait du reverse proxy pour plusieurs serveur Emby public. L'avantage d'une telle configuration, c'est que ton serveur Apache est le seul a être interrogé par les utilisateurs. Il se charge, après, de communiquer avec ton/tes serveurs Emby.

Là c'est un vrai argument.

53 minutes ago, Randdrick said:

Ainsi, ton serveur Emby n'est jamais directement exposé en frontale ce qui implique que si il y a une attaque, l'attaque se fera sur ton serveur Apache et non pas sur ton serveur Emby. Mais bon, faut pas pousser non plus. 

Dans le cas d'un simple serveur Emby, derrière ta box, cela apporte quand même en terme de sécurité car le principe de fonctionnement est le même si tu ouvres ton serveur en accès distant à d'autres utilisateurs. Il te suffira juste d'ouvrir le port 80 en entrée vers ton serveur Emby, ton reverse proxy sera chargera de  rediriger ton flux ver le port 8096 et l'encryptera.

Mais pas là On a exactement la meme surface exposée sur le port 80/443 via le reverse proxy que sur le port 8096 d'Emby. Il n'y a aucune raison qu'Apache arrête une attaque à destination d'Emby tel que c'est configuré actuellement dans le tutorial. Le chiffrement SSL est déjà géré par Emby. J'ai envie de dire que le problème principal ici c'est qu'on croit que c'est + sécurisé grace au reverse proxy alors que ce n'est absolument pas le cas.

 

Edited November 14, 2021 by neves000

[Randdrick 24]

1 hour ago, Mickelebof said:

@Randdrick as-tu la possibilité d'essayer avec Nginx ? Juste histoire d'écarter la possibilité que ça vienne d'Apache

Edit : Peut être un test à faire avant, as-tu essayé de rediriger vers le port 8920 au lieu du 8096 de ton Emby ?

En fait, j'ai fais mon boulet. Mais c'est en lisant vos posts que j'ai compris là ou cela n'allait pas.

J'avais enregistré Emby Theater en omettant de mettre https

En mettant https://monserveremby.ddns.net sans mettre de numéro de port, tout fonctionne sans problème.

1 hour ago, neves000 said:

Désolé d'insister, mais je ne suis pas d'accord avec la notion de sécurisation, avec le système mis en place dans le tutorial tel qu'il est actuellement :

• Emby sait déjà chiffrer la communication en SSL tout seul ;
• Dans le cas d'un forward de ports direct depuis le routeur vers un Emby SSL, on expose à un attaquant toute la surface d'Emby (ce qui est atteignable sur le port 8096)
• Dans le cas d'Emby derrière un reverse proxy, on expose encore à un attaquant toute la surface d'Emby à laquelle on ajoute celle du reverse proxy lui-même. Le reverse proxy seul ne va réaliser aucun filtrage sur ce qu'un attaquant va envoyer à Emby (Il faudrait ajouter un WAF). Alors je suis bien d'accord, c'est rare qu'on trouve des vulnérabilités dans nginx ou apache (même si on a eu droit à CVE-2021-41773 récemment), mais je suis partisan de l'option avec le moins de complexité possible.

Non, Emby ne sait pas le faire naturellement sauf si tu lui rentre un certificat de type PKS #12 (voir configuration réseau d'Emby). Tu peux le faire aussi avec Let's Encrypt mais ceci est un autre débat.
Le foward de port est une chose, le reverse proxy en est une autre.
Tu fais du foward de port pour t'éviter de rentrer monserveuremby.ddns.net:8096 par exemple.
C'est le reverse proxy qui te permet de sécuriser ta connexion. Pour en savoir plus sur reverse proxy, je te renvoie vers cet article : https://www.ionos.fr/digitalguide/serveur/know-how/quest-ce-quun-reverse-proxy-le-serveur-reverse-proxy/

Sinon, oui en effet il faudrait rajouter un WAF pour analyser ce que fait un attaquant et couper automatiquement sa communication en cas de doute. Mais faut pas pousser non plus. N'oublions pas non plus qu'une attaque se fait toujours des ports qui sont ouverts, et jamais par hasard. Si tu fermes le port 80 pour ouvrir le 8096, cela ne changera pas, et de plus tes communications transiteront en clair.

Quote

Mais pas là On a exactement la meme surface exposée sur le port 80/443 via le reverse proxy que sur le port 8096 d'Emby. Il n'y a aucune raison qu'Apache arrête une attaque à destination d'Emby tel que c'est configuré actuellement dans le tutorial. Le chiffrement SSL est déjà géré par Emby. J'ai envie de dire que le problème principal ici c'est qu'on croit que c'est + sécurisé grace au reverse proxy alors que ce n'est absolument pas le cas.

Pourquoi mettre un reverse Proxy ? 
Mon but n'est pas tant de me protéger d'une attaque, mais parce que je veux encrypter les communications et parce certaines SMART TV n'arrivent pas à joindre un serveur Emby sécurisé par un certificat de type PKS #12.
C'est d'ailleurs le firewall de mon hébergeur qui se charge d'analyser ce qui transite à travers mes ports 80 et 443. Et en plus, c'est gratuit. 
De plus, mon hébergeur va faire très attention sur les trames qui passent à travers les ports 80 et 443 car il héberge pleins de serveur web. Par contre, ce qui se passe sur les ports 8096 et 8920, il va s'en moquer... .

@Luke It's not a problem with Emby Theater but with my Emby theater configuration. It's solved. Thank You. To registrar an emby client with a reverse proxy you must type https://mon.domain.com and leave port blank
 

 

Edited November 14, 2021 by Randdrick

[neves000 15]

59 minutes ago, Randdrick said:

Non, Emby ne sait pas le faire naturellement sauf si tu lui rentre un certificat de type PKS #12 (voir configuration réseau d'Emby). Tu peux le faire aussi avec Let's Encrypt mais ceci est un autre débat.

Le format du certificat ne rentre pas en compte ici. PKCS#12 c'est une norme qui définit un format de fichier (J'imagine que tu mets ce format en face des fichiers PEM ou DER de ta configuration Apache). Pour faire une analogie un peu foireuse, tu peux avoir un fichier compressé en ZIP et le même fichier compressé en RAR, à la fin si tu décompresses les deux archives tu auras le même fichier. Ici on a un fichier au format pkcs12 et des fichiers PEM, à la fin tu as les même outils cryptographiques (clés, certificats) pour gérer le SSL de ton serveur.

Je n'ai pas mis en place le chiffrement SSL dans Emby parce que je n'en ai pas l'utilité chez moi, mais je suis presque sur que si, Emby sait gérer naturellement SSL (c'est dans les options réseaux en tout cas). Qu'on doive fournir les certificats et les clés dans un certain format ne change rien.

59 minutes ago, Randdrick said:

Le foward de port est une chose, le reverse proxy en est une autre.
Tu fais du foward de port pour t'éviter de rentrer monserveuremby.ddns.net:8096 par exemple.
C'est le reverse proxy qui te permet de sécuriser ta connexion. Pour en savoir plus sur reverse proxy, je te renvoie vers cet article : https://www.ionos.fr/digitalguide/serveur/know-how/quest-ce-quun-reverse-proxy-le-serveur-reverse-proxy/

C'est bien ce que je dis Si tu mets en place un reverse proxy UNIQUEMENT pour éviter d'avoir à taper un port, alors c'est inutile et ça affaiblie la sécurité en ajoutant une couche applicative.

Dans le tutorial, le reverse proxy ne sert qu'à ajouter une couche de chiffrement SSL, mais c'est inutile puisqu'Emby sait déjà le faire nativement. Il ne protège pas du tout dans le cas d'une vulnérabilité dans Emby. Il ne faut surtout pas faire croire que c'est sécurisé uniquement parce qu'il y a un petit cadenas dans la barre d'URL du navigateur

59 minutes ago, Randdrick said:

Sinon, oui en effet il faudrait rajouter un WAF pour analyser ce que fait un attaquant et couper automatiquement sa communication en cas de doute. Mais faut pas pousser non plus. N'oublions pas non plus qu'une attaque se fait toujours des ports qui sont ouverts, et jamais par hasard. Si tu fermes le port 80 pour ouvrir le 8096, cela ne changera pas, et de plus tes communications transiteront en clair.

Si j'ouvre un port sur mon routeur vers un Emby SSL (port 8920 apparemment, par défaut), les communications seront chiffrées, sans reverse proxy.

J'ajouterais que si, la majorité des attaques "grand publiques" est faite "par hasard". Dans le sens où quand une faille est trouvée dans un logiciel X, alors tous les pirates qui arrivent à exploiter la faille se mettent à scanner Internet pour trouver ce logiciel X et rajouter quelques machines dans des botnets ou des fermes de mining. Cela fait longtemps que les scans sont faits en permanence sur les ports classiques pour savoir où taper en avance.

Par exemple, avec un site comme shodan (il y en a d'autres), on peut déjà connaitre quelques (27313) serveurs Emby exposés sur Internet : https://www.shodan.io/search?query=Emby

59 minutes ago, Randdrick said:

Pourquoi mettre un reverse Proxy ? 
Mon but n'est pas tant de me protéger d'une attaque, mais parce que je veux encrypter les communications et parce certaines SMART TV n'arrivent pas à joindre un serveur Emby sécurisé par un certificat de type PKS #12.

Cela n'a pas de sens. S'il y a un problème avec certaines smart tv, il faut plutot regarder du coté des standards SSL/TLS que propose Emby. Rien à voir avec PKCS#12.

Quote

C'est d'ailleurs le firewall de mon hébergeur qui se charge d'analyser ce qui transite à travers mes ports 80 et 443. Et en plus, c'est gratuit. 

Si ton hébergeur peut analyser ce qui transite dans ton SSL sur le port 443, alors c'est qu'il fait un MITM SSL, qu'il a tes clés SSL et qu'il peut alors déchiffrer tout ton trafic SSL. J'imagine que ce n'est pas ce que tu veux. J'imagine que tu parlais d'une analyse directement sur ton serveur (ce qui revient au WAF sur le reverse proxy), plutôt que par ton hébergeur à distance ? (Je ne comprend pas l'argument de la gratuité, tout ce dont on parle depuis le début est gratuit).

Edited November 14, 2021 by neves000

[Randdrick 24]

@neves000

Alors, je reprécise une chose. J'ai un serveur Emby qui est sur un VPS, ce qui fait que j'ai une adresse ip publique. Si je mettais mon serveur Emby derrière ma box, ca n'aurait pas de sens que de faire un reverse proxy sur un serveur qui est chez moi... Ni même de sécuriser tout ça d'ailleurs.

Ceci étant : 
- Non, mon hébergeur n'a pas les clefs. Mais il analyse forcément ce qui va se passer sur ses firewalls. Qui dit VPS, dit machine hébergées dans ses datacenter, etc..
- Je veux rajouter une couche SSL car en effet je veux que les communications qui transitent entre différents clients et mon serveur Emby soient cryptées.
- Concernant Emby, si tu veux crypter tes communications quelque soit ton client, tu n'as pas d'autres choix que de mettre en place un reverse proxy avec une couche SSL (sinon problème avec certaines Smart TV qui pour le coup ne peuvent même pas se connecter au serveur). Les standards que proposent Emby sont ceux que tu trouves dans la configuration d'Emby et rien d'autre, à savoir :

- Pas de cryptage 
- Cryptage possible mais non obligatoire
- Cryptage obligatoire (qui implique de générer un certificat au format PKS #12 et d'avoir un nom de domaine. C'est ainsi qu'Emby gère le SSL). Ce type de configuration pose problème pour certaines Smart TV. 
- Reverse proxy.

C'est pour cela que j'ai précisé dans le tuto, la notion de firewall public. Je suis d'accord avec toi depuis le début. Faire un reverse proxy pour un serveur Emby hébergé derrière sa box, ça n'a pas de sens. 

Enfin, et je vais terminer par une lapalissade. Si tu as un serveur sur internet (Web, Emby ou autre) tu es forcément exposé. Si Emby a une faille de sécurité, ce n'est pas le port qui changera grand chose. 

Edited November 14, 2021 by Randdrick

[neves000 15]

16 minutes ago, Randdrick said:

Alors, je reprécise une chose. J'ai un serveur Emby qui est sur un VPS, ce qui fait que j'ai une adresse ip publique. Si je mettais mon serveur Emby derrière ma box, ca n'aurait pas de sens que de faire un reverse proxy sur un serveur qui est chez moi... Ni même de sécuriser tout ça d'ailleurs.

Pourquoi ? On peut avoir un Emby chez soit avec un port exposé sur Internet, c'est le même scénario, il faut le sécuriser pour ces accès externes.

Qu'il soit sur un VPS ne change pas que si tu mets un reverse proxy uniquement pour avoir du SSL, alors ce n'est pas utile puisqu'Emby sait le faire. Un peu d'iptables pour tout fermer sauf le port redirigé vers le port SSL d'Emby, et on est bon. Si tu as d'autres services sur le port 443 alors tu as une raison valable. Mais c'est encore la seule que je vois, suite à nos échanges ici.

16 minutes ago, Randdrick said:

Ceci étant : 
- Non, mon hébergeur n'a pas les clefs. Mais il analyse forcément ce qui va se passer sur ses firewalls. Qui dit VPS, dit machine hébergées dans ses datacenter, etc..

Non, ton hébergeur n'a aucun moyen de savoir ce qui transite dans ton flux SSL, c'est le principe de chiffrer la communication de bout en bout. Même si ça passe par ses machines. Ce qu'il peut savoir, c'est qu'une adresse IP a fait passer des données chiffrées dans du trafic SSL sur un port donné, mais jamais ce qu'il y a dedans. Il ne peut donc pas te protéger si un attaquant utilise ce flux chiffré pour réaliser une attaque, puisqu'il ne la voit pas.

16 minutes ago, Randdrick said:

- Je veux rajouter une couche SSL car en effet je veux que les communications qui transitent entre différents clients et mon serveur Emby soient cryptées.

C'est très bien Utilise Emby pour ça

16 minutes ago, Randdrick said:

- Concernant Emby, si tu veux crypter tes communications quelque soit ton client, tu n'as pas d'autres choix que de mettre en place un reverse proxy avec une couche SSL (sinon problème avec certaines Smart TV qui pour le coup ne peuvent même pas se connecter au serveur). Les standards que proposent Emby sont ceux que tu trouvent dans la configuration d'Emby et rien d'autre, à savoir :

- Pas de cryptage 
- Cryptage possible mais non obligatoire
- Cryptage obligatoire (qui implique de générer un certificat au format PKS #12 et d'avoir un nom de domaine. C'est ainsi qu'Emby gère le SSL). Ce type de configuration pose problème pour certaines Smart TV. 
- Reverse proxy.

Cela me semble faux. Si tu veux, tu peux transformer tes fichiers .pem que tu utilises dans ton reverse proxy Apache en format PKCS#12 pour qu'Emby les comprenne, et utiliser le même dyndns que tu as utilisé dans ton tutorial. Il n'y a aucune raison que cela ne fonctionne pas, sauf bug dans Emby.

De tête quelque chose comme ça :

openssl pkcs12 -export -inkey key.pem -in cert.pem -out private.p12

Peux-tu me pointer les messages qui parlent de ces problèmes de Smart TV incompatibles ?

Edited November 14, 2021 by neves000

[Randdrick 24]

15 minutes ago, neves000 said:

Peux-tu me pointer les messages qui parlent de ces problèmes de Smart TV incompatibles ?

Déjà ma SMART TV a ce problème (qui est une Philips 4K).    Il peut y en avoir d'autres.

17 minutes ago, neves000 said:

Non, ton hébergeur n'a aucun moyen de savoir ce qui transite dans ton flux SSL, c'est le principe de chiffrer la communication de bout en bout. Même si ça passe par ses machines. Ce qu'il peut savoir, c'est qu'une adresse IP a fait passer des données chiffrées dans du trafic SSL sur un port donné, mais jamais ce qu'il y a dedans. Il ne peut donc pas te protéger si un attaquant utilise ce flux chiffré pour réaliser une attaque, puisqu'il ne la voit pas.

Ce n'est pas mes trames qu'il va analyser, mais ce qui va  se passer sur ses firewall. Comme des attaques de deny de service par exemple et j'en passe.

Voici les modes de connexion qu'accepte Emby

22 minutes ago, neves000 said:

Si tu veux, tu peux transformer tes fichiers .pem que tu utilises dans ton reverse proxy Apache en format PKCS#12 pour qu'Emby les comprenne, et utiliser le même dyndns que tu as utilisé dans ton tutorial. Il n'y a aucune raison que cela ne fonctionne pas, sauf bug dans Emby.

Justement, il y a peut-être un bug dans Emby, qui touche que certains modèles de SMART TV. Ce n'est pas à mon sens un bug qui sera corrigé, surtout s'il est à la marge.
Encore une fois, je suis d'accord avec toi. Il est plus simple de générer un certificat de en format PKCS #12 et utiliser Emby pour ça que de s'embêter avec un reverse proxy avec une couche SSL. Mais là n'est pas le débat.

L'idée n'est pas de savoir qu'elle est la meilleure des solutions, mais de choisir la solution la plus adaptée en fonction de ses contraintes. D'où le tuto sur reverse proxy avec Apache, qui pourra servir à d'autres si besoin.

[neves000 15]

1 hour ago, Randdrick said:

Déjà ma SMART TV a ce problème (qui est une Philips 4K).    Il peut y en avoir d'autres.

Peux-tu sortir les logs Emby d'une tentative de login sur Emby SSL via ta TV ? S'il y a un problème dans Emby, il faut essayer de le résoudre. Je n'ai pas de Philips 4K pour essayer chez moi.

1 hour ago, Randdrick said:

Ce n'est pas mes trames qu'il va analyser, mais ce qui va  se passer sur ses firewall. Comme des attaques de deny de service par exemple et j'en passe.

Tu mélanges un peu tout

1 hour ago, Randdrick said:

Voici les modes de connexion qu'accepte Emby

Oui, où veux-tu en venir ? On voit bien qu'Emby est prévu pour géré SSL donc, même si c'est traduit maladroitement sans faire référence à cela.

1 hour ago, Randdrick said:

Justement, il y a peut-être un bug dans Emby, qui touche que certains modèles de SMART TV. Ce n'est pas à mon sens un bug qui sera corrigé, surtout s'il est à la marge.

Qu'un périphérique ne puisse pas se connecter en SSL à Emby est un bug grave à mes yeux, qui doit être corrigé. Surtout qu'il s'agit sans doute d'une histoire de version de SSL/TLS à supporter.

 

Quote

Enfin, et je vais terminer par une lapalissade. Si tu as un serveur sur internet (Web, Emby ou autre) tu es forcément exposé. Si Emby a une faille de sécurité, ce n'est pas le port qui changera grand chose. 

C'est effectivement ce que je dis depuis le début (modulo le fait que tu es + exposé via les scanneurs sur des ports classiques que sur des ports aléatoires). Tu ne peux pas parler de sécurisation d'Emby quand au final le tutorial ne fait qu'ajouter une surface d'attaque supplémentaire : s'il y a une faille dans Emby, elle restera atteignable via le reverse proxy tel qu'il est configuré actuellement dans le tutoriel. Ce sont les termes utilisés dans le tutorial qui me font tiquer : on ne sécurise pas Emby, on ajoute juste une couche de SSL.

 

Edit : Je te confirme que si je peux me connecter sans problème à Emby en SSL avec mon navigateur Web, ma TV LG n'y arrive pas. Il y a sans doute bien un bug ici ! Sans doute dans le client, je ne vois rien de particulier dans les logs du serveur. Et comme on a perdu tout espoir que l'application Emby soit mise à jour sur le LG store, c'est foutu pour le corriger ...

Edited November 14, 2021 by neves000

[Randdrick 24]

1 hour ago, neves000 said:

Tu mélanges un peu tout

Non je ne pense pas. Même s'il est clair que tu en connais bien plus que moi sur le sujet. Par contre, je te l'accorde, je prend des raccourcis. Plus précisément donc, j'ouvre les ports qui me sont nécessaires au niveau du pare-feu de mon hébergeur pour administrer mon serveur Emby, et rien d'autre. Quant aux différentes sondes d'analyses, systèmes anti intrusions, etc dont il dispose pour sa sécurité, je ne les connais pas bien entendu. Je ne peux faire que le pari que j'en bénéficie indirectement.

1 hour ago, neves000 said:

Edit : Je te confirme que si je peux me connecter sans problème à Emby en SSL avec mon navigateur Web, ma TV LG n'y arrive pas. Il y a sans doute bien un bug ici ! Sans doute dans le client, je ne vois rien de particulier dans les logs du serveur. Et comme on a perdu tout espoir que l'application Emby soit mise à jour sur le LG store, c'est foutu pour le corriger ...

Je te remercie pour la confirmation de ce bug. Si tu montes un reverse proxy à travers apache ou autre, tu verras que ta télé peut se connecter en SSL. Je pense que c'est le rewriting qui le permet. A tester donc sans faire de redirection de port (puisque tu n'es pas pour. LoL).
Ma TV est une Android TV. Est-ce le client Emby qui pose problème, la prise en charge du format des certificats par certains constructeurs... Là, je pense que l'on ne le saura jamais.

1 hour ago, neves000 said:

Tu ne peux pas parler de sécurisation d'Emby quand au final le tutorial ne fait qu'ajouter une surface d'attaque supplémentaire : s'il y a une faille dans Emby, elle restera atteignable via le reverse proxy tel qu'il est configuré actuellement dans le tutoriel. Ce sont les termes utilisés dans le tutorial qui me font tiquer : on ne sécurise pas Emby, on ajoute juste une couche de SSL

Alors là, on est dans une vue d'esprit. Rajouter une couche de SSL, donc crypter le flux, c'est rajouter une couche de sécurité quoique l'on en dise ou pense. Ca serait vraiment très bête de se faire snifer le compte et mot de passe, tout ça parce que ta communication n'est pas cryptée, n'est-ce pas ?
On peut aussi débattre de la surface d'attaque, qui certes est mathématiquement plus exposée sur les ports 80 et 443. Mais shodan lui se fiche de savoir quels sont les ports qui sont ouverts puisqu'il remonte tous les ports ouverts de tout ce qu'il trouve de connecté sur le web.
Et puis, je vais prendre exprès un peu le contre-pieds de tout ça. Qu'est-ce qui attire le plus la curiosité d'un pirate ? Savoir ce qui se passe derrière un port 8096, peu connu, ou un port 80, qui lui est très connu ? Bref le débat est un peu sans fin, et tous les arguments sont bons.

Au niveau sécurité, à partir du moment ou j'expose un serveur applicatif, je me fixe les règles de base suivantes :

- Avoir mon OS et mon application toujours à jour, à la dernière version.
- Avoir que le minimum nécessaire installé. 
- Ouvrir que les ports nécessaires au bon fonctionnement de mon application.
- Autoriser, si possible, seulement les adresses IP qui ont le droit d'y accéder.
- Générer un login complexe (Compte et mot de passe).

Le problème n'est pas de savoir si on peut être piraté (car il est évident qu'on peut l'être, tout dépend du temps dont dispose l'attaquant) mais de rentre la tâche la plus difficile pour éviter justement au commun du kikoolol du piratage qui utilise un bot tout fait de mettre son fichu programme de crypto minage sur ton serveur. (Pour reprendre ton exemple)

[neves000 15]

12 hours ago, Randdrick said:

Non je ne pense pas. Même s'il est clair que tu en connais bien plus que moi sur le sujet. Par contre, je te l'accorde, je prend des raccourcis. Plus précisément donc, j'ouvre les ports qui me sont nécessaires au niveau du pare-feu de mon hébergeur pour administrer mon serveur Emby, et rien d'autre. Quant aux différentes sondes d'analyses, systèmes anti intrusions, etc dont il dispose pour sa sécurité, je ne les connais pas bien entendu. Je ne peux faire que le pari que j'en bénéficie indirectement.

On parlait d'analyser le contenu des requêtes pour bloquer un éventuel attaquant (en utilisant par exemple un WAF). Ce que je voulais dire c'est que ton hébergeur ne peux pas inspecter le contenu de ton flux SSL. Il peut en effet bloquer une tentative de DDoS quand il voit trop de requêtes mais ça s’arrête là. Ce que je veux mettre en avant, c'est qu'il faut arrêter de croire que quelque chose est sécurisé uniquement parce que ça passe dans un tunnel SSL. Le fameux "c'est sécurisé parce qu'il y a un cadenas dans la barre en haut du navigateur"

 

12 hours ago, Randdrick said:

Je te remercie pour la confirmation de ce bug. Si tu montes un reverse proxy à travers apache ou autre, tu verras que ta télé peut se connecter en SSL. Je pense que c'est le rewriting qui le permet. A tester donc sans faire de redirection de port (puisque tu n'es pas pour. LoL).
Ma TV est une Android TV. Est-ce le client Emby qui pose problème, la prise en charge du format des certificats par certains constructeurs... Là, je pense que l'on ne le saura jamais.

Je ne pense pas que le rewriting soit la raison pour laquelle la TV arrive à se connecter, il n'y a pas vraiment de raison. Les raisons les plus probables sont :

• Le client Emby sur la TV n'accepte pas un certificat self signé (si c'est le cas) et ne remonte pas l'erreur. < ça a l'air d'être le problème chez moi.
• Le client Emby sur la TV ne comprend pas les protocoles SSL supportés par le serveur Emby et ne remonte pas l'erreur.
• Quelque chose qui m'échappe

On peut exclure le fait que le client Emby sur la TV ne connaisse pas la CA (ici Let's Encrypt) qui a servis à signer le certificat du serveur puisqu'il l'accepte en passant par ton reverse-proxy.

Je le répète : le format PKCS12 des certificats n'a AUCUNE incidence sur le flux SSL. Emby pourrait accepter des fichier PEM que le comportement/bug serait identique. Le serveur, que ça soit Apache ou Emby, extrait des fichiers (PEM ou p12) les clés et certificats cryptographiques (qui sont les même dans les deux cas) et s'en sers pour établir son chiffrement.

Voilà les protocoles SSL que propose Emby :

nmap --script ssl-enum-ciphers -p 8920 IP_EMBY
Starting Nmap 7.92 ( https://nmap.org ) at 2021-11-15 12:08 CET
Host is up (0.00028s latency).

PORT     STATE SERVICE
8920/tcp open  unknown
| ssl-enum-ciphers: 
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 4096) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 4096) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.95 seconds

Donc TLSv1.1 et  TLSv1.2 uniquement. Si le client Emby veut faire autre chose que ça, ça ne fonctionnera pas.

 

12 hours ago, Randdrick said:

Alors là, on est dans une vue d'esprit. Rajouter une couche de SSL, donc crypter le flux, c'est rajouter une couche de sécurité quoique l'on en dise ou pense. Ca serait vraiment très bête de se faire snifer le compte et mot de passe, tout ça parce que ta communication n'est pas cryptée, n'est-ce pas ?

Évidemment, je ne peux pas contredire ça. Ma réflexion était basée sur le fait qu'Emby sache déjà faire correctement son serveur SSL.

 

12 hours ago, Randdrick said:

On peut aussi débattre de la surface d'attaque, qui certes est mathématiquement plus exposée sur les ports 80 et 443. Mais shodan lui se fiche de savoir quels sont les ports qui sont ouverts puisqu'il remonte tous les ports ouverts de tout ce qu'il trouve de connecté sur le web.

Non, shodan scan les ports les plus couramment utilisés, en boucle. Le port que j'utilise pour mon Emby ne sera jamais dans shodan (surtout qu'il y a un filtrage IP dessus pour chaque personne autorisée).

 

12 hours ago, Randdrick said:

Et puis, je vais prendre exprès un peu le contre-pieds de tout ça. Qu'est-ce qui attire le plus la curiosité d'un pirate ? Savoir ce qui se passe derrière un port 8096, peu connu, ou un port 80, qui lui est très connu ? Bref le débat est un peu sans fin, et tous les arguments sont bons.

Ce n'est pas comme ça qu'il faut réfléchir. On ne parle pas de curiosité mais d'opportunité. Bien sûr, il ne faut pas exposer le port 8096 puisqu'un attaquant sait automatiquement ce qu'il se trouve derrière. Il scan Internet (ipv4) aujourd'hui sur ce port (en quelques jours) et il se fait une belle liste de serveurs Emby à péter s'il a une vulnérabilité.

Les ports 80 et 443 sont scannés en permanence, et l'exemple de shodan montre qu'on peut facilement identifier un serveur Emby même sur ces ports. Le problème est le même. Le jour où une vulnérabilité tombe dans Emby, la première chose que va faire un attaquant c'est sortir son scan des ports 8096 (et 8920) et y ajouter les 23000 Emby qu'on trouve sur shodan sur les ports 80/443.

Comme on peut filtrer par port (443), serveur (Apache), pays (France), avec un compte sur shodan, il y a de fortes chances qu'on puisse aujourd'hui déjà identifier ton serveur Emby sur ton VPS.

 

12 hours ago, Randdrick said:

Au niveau sécurité, à partir du moment ou j'expose un serveur applicatif, je me fixe les règles de base suivantes :

- Avoir mon OS et mon application toujours à jour, à la dernière version.
- Avoir que le minimum nécessaire installé. 
- Ouvrir que les ports nécessaires au bon fonctionnement de mon application.
- Autoriser, si possible, seulement les adresses IP qui ont le droit d'y accéder.
- Générer un login complexe (Compte et mot de passe).

Le problème n'est pas de savoir si on peut être piraté (car il est évident qu'on peut l'être, tout dépend du temps dont dispose l'attaquant) mais de rentre la tâche la plus difficile pour éviter justement au commun du kikoolol du piratage qui utilise un bot tout fait de mettre son fichu programme de crypto minage sur ton serveur. (Pour reprendre ton exemple)

C'est très bien.

Edited November 15, 2021 by neves000