Aller au contenu

Messages recommandés

Posté(e) (modifié)
il y a 35 minutes, .Shad. a dit :

@Alexis Toyane Est-ce que tu peux vérifier par SSH ce que renvoient les commandes :

cat /etc/resolv.conf

nslookup plex.ndd.fr

nslookup plex.ndd.fr 8.8.8.8

netstat -tunlp | grep 443

Tiens, étant curieux, j'ai lancé les 4 commandes, en root sur mon NAS 😉

Pour les nslookup, est-ce que ce que j'ai semble normal ? @.Shad.
Je précise que 192.168.2.210 est l'IP de mon conteneur AdGuardHome qui fait office de serveur DNS local, mais qui utilise des UPStream particuliers (voir capture après). J'ai aussi mis une réécriture DNS de *.mon-nas.mon-ndd.ovh vers l'IP de mon NAS. 
A9nb9Dp.png

Z7wJ83P.png
Les serveurs d'amorçage sont : cPvSA4k.png

 

 

 

Modifié par MilesTEG1
Posté(e)

@MilesTEG1 Tu devrais être capable de le savoir maintenant. 😛 

@Alexis Toyane On va tester un truc pour mettre hors de cause le routeur et le NAT. Tu édites ton fichier C:\Windows\System32\drivers\etc\hosts et tu ajoutes la ligne :

plex.ndd.fr            IP_LOCALE_DU_NAS

Puis tu tentes de nouveau d'y accéder en précisant bien HTTPS.

Posté(e) (modifié)
Il y a 10 heures, .Shad. a dit :

@Alexis Toyane On va tester un truc pour mettre hors de cause le routeur et le NAT. Tu édites ton fichier C:\Windows\System32\drivers\etc\hosts et tu ajoutes la ligne :




plex.ndd.fr            IP_LOCALE_DU_NAS

Puis tu tentes de nouveau d'y accéder en précisant bien HTTPS.

J’ai fait l’équivalent de ce changement sur MAC (donc dans /etc/hosts) et désormais plex.ndd.fr renvoie bien vers Plex (sur cette machine uniquement évidemment).
Du coup je comprends que le problème est soit sur le routeur soit sur le NAT ? 🙂 

 

Bon, j’ai trouvé !  Merci @.Shad. et @MilesTEG1 !
Problème au niveau du NAT qui avait une règle qui renvoyait du port 443 vers le 5001 (et donc DSM)... Ça m’a rendu fou ! Merci beaucoup pour l’aide. 

Modifié par Alexis Toyane
Posté(e)

Bonjour,

suivant depuis l'achat de mon NAS en 2018 la plupart des tutos et discussions intéressantes sur ce site, je n'ai jamais pris le soin de m'inscrire car les tutos permettent de s'en sortir sans avoir à poser de questions (!! well done), ni de donner mon avis qui est bien moins pertinents que ceux des utilisateurs avisés ici !

Mais pour le coup, je me pose une question quant au Reverse Proxy (à moins qu'elle ait déjà été posée mais je ne l'ai pas vu).

Si on estime que le reverse proxy a l'avantage de laisser ouvert le moins de ports possible sur notre acces réseau (box internet), qu'en est-il des attaques possibles sur les applications elles-mêmes. Si je comprends bien, je veux dire que l'acces depuis l'extérieur aux dîtes applications se feront par le -p 443, celui privilégié par les attaques de bot non ? N'y a-t-il pas moyen de pénétrer dans le NAS par le biais d'une application redirigée ici ?

Est-ce que du coup on ne s'expose pas une potentielle pénétration (ou flooding) sur notre NAS qui sera visible par le -p 443 ?

Je me pose la question car j'avais testé à mes débuts sur le NAS le QuickConnect (ne me tapez pas svp, je voulais voir et me faire un avis 😛), qui permettait ce genre "d'attaque" de bot je pense (je voyais des IP inconnues échouer la connexion depuis différents pays). J'avais aussi ensuite configuré l'acces à mon NAS depuis le -p 443 (pour des raisons pratiques), qui avait donné lieu aux mêmes genres "d'attaque". J'ai sécurisé depuis grâce aux tutos de Fenrir notamment 🙂 !

Du coup je me demande à quel point est-ce sécurisé d'accéder à toutes ses applications NAS depuis le port 443 car je comprends que le reverse proxy redirigera automatiquement l'acces extérieur vers le bon port du NAS.

 

Je ne sais pas si je me ferai bien comprendre, ni si ma question est légitime, mais je suis bien curieux de savoir comment le reverse proxy permet de "sécuriser" ce genre d'intrusion.

 

Et merci pour ce tuto, et pour tous les autres aussi, bien évidemment !

Posté(e)

Le port 443 n'est pas plus protégé qu'un autre, c'est juste qu'il est chiffré (mais comme peuvent l'être tous les ports) par défaut par il correspond au port utilisé par défaut par HTTPS.
Quand tu tapes un login et mot de passe sur une page chiffrée, un man in the middle (MITM) peut tout à fait intercepter tout ce qui est échangé, mais ne pourra pas le déchiffrer.

Ton proxy inversé est l'unique porte, que tu peux blinder à souhait, pour rentrer chez toi.
Tu peux appliquer du 2FA à cette porte (voir Authelia), du fail2ban, des conditions GeoIP avec le pare-feu du NAS, etc...

Par contre, tu peux blinder autant que tu veux, mais si tu utilises admin/admin comme credentials, bah ça ne changera rien. ^^

Posté(e)
il y a une heure, youbov a dit :

Est-ce que du coup on ne s'expose pas une potentielle pénétration (ou flooding) sur notre NAS qui sera visible par le -p 443 ?

Ça dépend de ce que laisse passer ton pare-feu comme sources. Plus tu restreins les sources qui peuvent contacter ton NAS, plus tu diminues ce risque.

Posté(e)
il y a 3 minutes, PiwiLAbruti a dit :

Ça dépend de ce que laisse passer ton pare-feu comme sources. Plus tu restreins les sources qui peuvent contacter ton NAS, plus tu diminues ce risque.

Bonjour, oui je comprends bien. Mais je me pose la question de la pertinance sur la sécurité par rapport à ça.

Si par exemple on ne configure aucune des app NAS sur le p 443, on n'aura jamais d'attaque de bot (qui se concentre sur les acces 443 j'ai cru comprendre). Alors que si on configure l'acces au NAS par le p 443, qui en plus centralisera toute les appli, on s'expose à ces bot ?

Je sais pas si c'est une vision de l'esprit, mais je pense préférer ne voir aucune tentative d'intrusion chez moi (même bloquée) que de voir ce genre connexions venir toquer à ma porte. Car quand ma config l'était ainsi, je me tapais souvent des 50aines de tentatives selon les jours, et quasi tous les jours. Ça rendait illisible les acces et connexions "normales" sur mon NAS. À ma connaissance, le seul point pour bloquer les intrus était de n'autoriser que les IP connues (?).

En tout cas, d'après votre réponse, je crois comprendre que le reverse proxy réouvre l'acces au NAS de façon "publique" ?

Du coup, est-ce qu'il serait pertinent de penser faire passer le nom de domaine par un autre port que le 443 ? Le hic serait que l'acces à mon NAS depuis l'extérieur sera dépendant du pare-feu mis en place sous la connexion extérieure ?

 

Pour ceux qui utilisent ce reverse proxy, avez-vous ce genre de tentative d'intrusion déjà ? et si oui, avez-vous réussi à les bloquer de manière pérenne sans avoir à n'autoriser que les IP connues ? (je pars aussi du principe que de n'autoriser que les IP venant de France n'est pas forcément pertinents vis à vis des VPN ?)

il y a une heure, .Shad. a dit :

Tu peux appliquer du 2FA à cette porte (voir Authelia), du fail2ban, des conditions GeoIP avec le pare-feu du NAS, etc...

J'ai déjà tout ça de configuré (le 2FA n'est que pour mon compte admin pour ne pas alourdir la connexion des autres utilisateurs).

Je pense que j'essaierai de faire cette configuration par nom de domaine qui me parait vraiment pratique, et au moins par curiosité quitte à l'enlever par la suite. C'est juste que je me dis qu'avec ça, "j'exposerai" plusieurs entrées (par les diverses applis) à ce genre d'attaque et ça me parait contre-intuitif. J'essaie de cheminer dans mon raisonnement.

il y a une heure, .Shad. a dit :

mais si tu utilises admin/admin

😄 merci, j'ai bien suivi les conseils de sécurité sur les autres tutos et c'est le 1e truc que j'ai fait !

Posté(e) (modifié)
il y a une heure, youbov a dit :

Si par exemple on ne configure aucune des app NAS sur le p 443, on n'aura jamais d'attaque de bot

Tous les ports sont concernés par les scans. Peu importe le port derrière lequel est configuré un service, il sera toujours facilement repérable.

Pour l'anecdote, il y a un botnet qui tourne actuellement et qui n'utilise que des adresses IP Françaises (tous opérateurs confondus), il concentre ses scans sur les ports supérieurs à 50000.

il y a une heure, youbov a dit :

En tout cas, d'après votre réponse, je crois comprendre que le reverse proxy réouvre l'acces au NAS de façon "publique" ?

Ça n'a rien à voir. On peut très bien utiliser le reverse proxy en local sans l'ouvrir sur internet. 

il y a une heure, youbov a dit :

Du coup, est-ce qu'il serait pertinent de penser faire passer le nom de domaine par un autre port que le 443 ?

Il faudra systématiquement préciser ce port dans les URL, sinon ça n'a rien de gênant.

il y a une heure, youbov a dit :

Le hic serait que l'acces à mon NAS depuis l'extérieur sera dépendant du pare-feu mis en place sous la connexion extérieure ?

Je n'ai pas compris 😅

Modifié par PiwiLAbruti
Posté(e)

@youbov puisque vous parcourez souvent ce forum, vous avez probablement remarqué qu'il y a une section pour les présentations. Il est d'usage ici comme sur beaucoup de forums d'aller y faire un tour avant de poster.

Je ne comprends pas cette discussion. A partir du moment où il y a quelque chose d'ouvert, il y aura tôt ou tard des tentatives d'intrusion. La seule arme réellement efficace, c'est de ne pas ouvrir son réseau sur l'extérieur ou mieux, de ne pas avoir de connexion internet.

Si on le fait, on sait qu'on s'expose. On ne peut pas empêcher quelqu'un ou un bot de s'adresser à une ip publique. Le tout est de faire en sorte de limiter au maximum les possibilités d'accès et de les rendre les plus compliquées possible tout en étant exploitables. Reverse proxy ou pas, ce qui est important, ce sont les réglages effectués au niveau du parefeu, des mdp forts (voir le tuto sur la sécurité), plus quelques précautions comme le fail2ban pour bloquer les intrus ou du moins limiter au maximum les risques d'intrusion. Généralement, si c'est trop compliqué, un hacker ne s'attarde pas et va tenter sa chance ailleurs.

Posté(e)

Effectivement @PiwiLAbruti. On peut créer des profils de contrôle d'accès.

Pour ma part, j'ai un profil "local" que j'applique pour mes ndd locaux tels que routeur.ndd, nas.ndd, mes cams.ndd etc. Les autres accessibles via le WAN sont protégés par les règles du parefeu. Mais on peut en créer d'autres pour des applications plus encadrées.

Posté(e) (modifié)

Bonjour, depuis le temps que je dois le faire je vais enfin me lancer. (j’espère qu'avec l'arrivée fin d'été 2021 de DSM 7 tout ne sera pas à refaire ...)

Je souhaite accéder à photo station via le reverse proxy, ayant fait une recherche sur ce même post j'ai vu qu'il fallait modifier le fichier .htaccess et ajouter un websocket dans le reverse proxy.

Par contre côté configuration photo station, j'imagine qu'il faut désactiver la redirection automatique des flux HTTP vers HTTPS ? 

Côté routeur, je ne touche à rien, transfert de port 443 vers le NAS.

C'est bien ça ?

Modifié par Diabolomagic
Posté(e)
il y a 25 minutes, Diabolomagic a dit :

j'ai vu qu'il fallait modifier le fichier .htaccess et ajouter un websocket dans le reverse proxy.

Heu websocket ? Tu es sûr ?
Moi j'ai juste ajouté ça : (qui redirige mon photo.monnas.ndd.tld vers http://photo.monnas.ndd.tld/photo/ et aussi qui fait la redirection HTTP vers HTTPS pour les noms de domaines) :
sachant que dans mon compte OVH photo.monnas.ndd.tld pointe vers monnas.ndd.tld qui est mon DynHost et donc pointe vers mon IP internet (pas fixe, Orange...) :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} ^photo.monnas.ndd.tld$
RewriteRule ^$  https://photo.monnas.ndd.tld/photo [L,R=301]

APrès, y a peut-être d'autres façons de faire...

Posté(e)
il y a 45 minutes, MilesTEG1 a dit :

Heu websocket ? Tu es sûr ?

@Diabolomagic  oui je ne l'ai pas activé non plus. Pour info j'avais mis en place ce reverse proxy avec DSM6 et suis passé à DSM7 béta sans problème 😉

Posté(e)
il y a 1 minute, Diabolomagic a dit :

Concernant la redirection automatique du HTTP vers HTTPS dans photostation l'avez vous coché ou pas ?

Surtout pas. Cette option est incompatible avec le proxy inverse c'est pour cela que l'on utilise soit un fichier .htaccess soit un fichier .php pour la redirection.

 

il y a 4 minutes, Diabolomagic a dit :

J'avais cru comprendre cela, page 40

oui mais chez moi ça fonctionne sans. Alors essaie les deux.

Posté(e)

@Jeff777

OK merci à toi, et derniére question aprés je vais essayer de faire fonctionner ma tête.

Dans photostation tu as alloué un port HTTP et un HTTPS ? (normalement le port HTTPS est inutile puisque c'est le reverse proxy qui s'en charge, non ?)

@MilesTEG1

J'ai oublié de te remercier pour le partage du bout de code dans ton htaccess qui concerne photo station 🙂 alors merci !

Posté(e)
il y a 2 minutes, Diabolomagic a dit :

(normalement le port HTTPS est inutile puisque c'est le reverse proxy qui s'en charge, non ?)

oui

Posté(e)
il y a une heure, Diabolomagic a dit :

Concernant la redirection automatique du HTTP vers HTTPS dans photostation l'avez vous coché ou pas ?

Chez moi elle était cochée...

il y a une heure, Jeff777 a dit :

Surtout pas. Cette option est incompatible avec le proxy inverse c'est pour cela que l'on utilise soit un fichier .htaccess soit un fichier .php pour la redirection.

Mais avec ce message je viens de décocher la case 🙂

Cependant je n'avais pas de soucis avant le décochage

il y a une heure, Diabolomagic a dit :

Dans photostation tu as alloué un port HTTP et un HTTPS ? (normalement le port HTTPS est inutile puisque c'est le reverse proxy qui s'en charge, non ?)

Moi j'ai rien défini dans photostation. Faut définir un port ?

il y a une heure, Diabolomagic a dit :

J'ai oublié de te remercier pour le partage du bout de code dans ton htaccess qui concerne photo station 🙂 alors merci !

De rien 🙂

 

Posté(e)

Bon par contre, je viens de voir que j'ai un soucis depuis que j'ai revu mes certificats, et que j'ai viré celui du nas.ndd.tld car devenu inutile... 

Du coup là avec mon nom de domaine photo.monnas.ndd.tld j'ai une erreur de certificat invalide... Logique après avoir regardé les certificats, je n'ai plus de certificat pour ce domaine... ni même inclus dans un autre...

ok.

J'en crée un, mais je ne vois pas comment affecter ce certificat à PhotoStation... C'est possible ça ?

J'ai essayé de refaire une règle dans le reverse-proxy après avoir mis un port sur le HTTPS dans PhotoStation : mais maintenant j'ai ce message (avec ou sans le .htaccess tel que donné précédemment) :
lEFa4QT.png

 

Bon du coup, bah je vois plus comment faire...
J'apprécierais pas mal un peu d'aide ^^

____________ Précision :
Actuellement j'ai mon nom de domaine chez ovh monnas.ndd.tld
avec des "sous"-domaines comme photo.monnas.ndd.tld ou cameras.monnas.ndd.tld ou plex.monnas.ndd.tld, drive.monnas.ndd.tld etc...
Chacun de ces domaines à son certificat dans le NAS. Sauf le monnas.ndd.tld vu que j'ai supprimé l'accès depuis le NET à DSM (passage par le VPN).

J'ai créé aussi un nom de domaine chez synology pour les services suivants :
HDiusmH.png

(un peu comme @.Shad. a fait, probablement en mieux réalisé chez lui 🙂 )

 

 

Merci de votre aide.

Posté(e)

Bonjour,

Rectificatif. Concernant la redirection de http vers https à ne pas cocher je voulais parler de la redirection générale.Celle de photostation je ne vois pas trop de quoi vous parlez tous les deux. 

Posté(e)

Bon pour mon problème avec PhotoStation, la seule solution que j'ai trouvé, c'est de passer par le nom de domaine wildards Synology.me, en mettant photos.monndd.synology.me/photo ça refonctionne sans erreur.
Il ne faut pas faire d'entrée dans le reverse proxy.

Je vais aller modifier le .htaccess pour refléter ce nouveau nom de domaine.

 

C'est une limitation bien pourrie du reverse-proxy de DSM et/ou de l'application PhotoStation... de ne pas avoir une entrée dans la liste des applications :
gGC45Bw.png

 

@.Shad. Tu as pu faire un certificat pour PhotoStation via SWAG ?

Posté(e) (modifié)
il y a une heure, Jeff777 a dit :

Bonjour,

Rectificatif. Concernant la redirection de http vers https à ne pas cocher je voulais parler de la redirection générale.Celle de photostation je ne vois pas trop de quoi vous parlez tous les deux. 

@Jeff777

Une petite photo vaut bien + qu'un long laïus 🙂

603819497_Capturedcran2021-05-13100032.thumb.jpg.c13a6a3d5c4859b94548ea89148ab7b6.jpg

il y a 33 minutes, MilesTEG1 a dit :

Bon pour mon problème avec PhotoStation, la seule solution que j'ai trouvé, c'est de passer par le nom de domaine wildards Synology.me, en mettant photos.monndd.synology.me/photo ça refonctionne sans erreur.
Il ne faut pas faire d'entrée dans le reverse proxy.

Je vais aller modifier le .htaccess pour refléter ce nouveau nom de domaine.

@MilesTEG1

Il me semblait que c'était payant un certif wildcard --> *.monndd.synology.me

Modifié par Diabolomagic
correction faute d'orthographe

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.