Aller au contenu

Messages recommandés

Posté(e)

Bonjour

J'utilise le reverse proxy pour accéder à mes synos, et ce avec un nom de domaine et sous domaine.
Tout fonctionne parfaitement.

J'ai mis en place la sécurité de blocage ip. J'ai fais un test de l’extérieur pour voir si le blocage fonctionne.

Que n'est pas ma surprise ! c'est l'adresse ip du syno abritant le reverse proxy qui est bloquée !!!
Et comme tout passe par lui, je n’accède plus au syno pointé par le reverse proxy et ce quelque soit l'adresse ip extérieure !!! vu que c'est sa propre adresse qui est bloquée.

 

Donc il suffit qu'un petit malin essaye d’accéder à un de mes sous domaines, le syno bloque l'adresse ip de mon reverse proxy et zou ! plus personne ne peux y accéder !

C'est pas banal comme situation, et bien sur moi-même de l’extérieur, je ne peux pas débloquer la situation !!!!

 

Merci de vos idées sur ce problème.

 

Posté(e)

@dadoupipo

Bonjour,

il y a 35 minutes, dadoupipo a dit :

J'ai mis en place la sécurité de blocage ip.

Tu peux préciser ce que tu as fait exactement. Action dans le pare-feu ou définition d'un profil de contrôle d'accès dans le reverse proxy ou autre chose encore ?

Possible que tu ais un blocage trop large sur une plage d'@IP qui contient en fait ton @IP externe sur la quelle pointe ton domaine, d'où tes déboires ...

Cordialement

oracle7😉

Posté(e)
Il y a 3 heures, dadoupipo a dit :

c'est l'adresse ip du syno abritant le reverse proxy qui est bloquée !!!

Il faut utiliser localhost comme hôte local dans la configuration du reverse proxy, et définir une liste blanche dans le blocage automatique des IP.

Posté(e)

bonjour

Merci pour vos réponses.

Pour répondre à Oracle7, j'ai mis le blocage auto dans le pare feu du syno que pointe le reverse proxy, Pas de profil de contrôle d'accès.

Je ne peux pas utiliser localhost dans le reverse proxy, car je fais appel à d'autres synology physiques, d'où une adresse ip.

Comment résoudre ce problème, utiliser le profil de contrôle d'accès ?

 

merci à vous

Posté(e) (modifié)

@dadoupipo

Bonjour,

Le 14/10/2022 à 10:49, dadoupipo a dit :

c'est l'adresse ip du syno abritant le reverse proxy qui est bloquée !!!

D'une part et tout bêtement, as-tu au moins vérifié que cette @IP n'est pas dans la liste des @IP bloquées (Sécurité / Protection / Autoriser/bloquer la liste / Liste des blocages) ? Si oui, supprimes la tout simplement de la dite liste.

D'autre part, ensuite je t'invite à suivre le conseil avisé de @PiwiLAbruti :

  • pour l'usage de "localhost" dans l'@ de destination de ta règle de revers proxy,
  • et pour mettre l'@IP de ton NAS qui supporte le reverse proxy dans la liste des @IP autorisées (Sécuurité / Protection / Autoriser/bloquer la liste / Liste des permissions).

C'est pas plus compliqué et on ne peut plus clair, non ?

Saches aussi que mettre "localhost" c'est exactement la même chose que de mettre l'@IP du NAS reverse proxy ou que de mettre 127.0.0.1. "localhost" n'est qu'un alias de ces @IP repectives et ce quelque soit le fait que tu fasses appel à d'autres Synology "physiques" dans tes règles de reverse proxy.

Sinon tu peux STP préciser ton assertion plus que confuse :

Il y a 2 heures, dadoupipo a dit :

j'ai mis le blocage auto dans le pare feu du syno que pointe le reverse proxy

???

Accessoirement : Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait).

Cordialement

oracle7😉

Modifié par oracle7
Posté(e) (modifié)

Merci de vos réponses

@oracle7@PiwiLAbruti

Il y a 2 heures, PiwiLAbruti a dit :

définir une liste blanche dans le blocage automatique des IP.

J'ai essayé de mettre donc l'ip du syno qui fait le reverse proxy dans le syno applicatif, plus de blocage effectivement, mais cela ne sert plus à rien, si l'ip externe à l'origine de l'attaque, n'est plus du tout bloquée !!!
J'ai fait l'essai.

 

il y a 28 minutes, oracle7 a dit :

Saches aussi que mettre "localhost" c'est exactement la même chose que de mettre l'@IP du NAS reverse proxy ou que de mettre 127.0.0.1. "localhost" n'est qu'un alias de ces @IP repectives et ce quelque soit le fait que tu fasses appel à d'autres Synology "physiques" dans tes règles de reverse proxy.

le revere proxy est sur un syno et l'application est sur un autre syno physique, donc je ne peux pas utiliser le localhost dans le reverse proxy qui fait référence à lui-même !!! et non pas le syno à atteindre

 

Bien à vous et merci de votre aide

 

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

J'ai essayé de mettre donc l'ip du syno qui fait le reverse proxy dans le syno applicatif, plus de blocage effectivement, mais cela ne sert plus à rien, si l'ip externe à l'origine de l'attaque, n'est plus du tout bloquée !!!

Synology ne propose pas de solution pour ce cas d'usage, et c'est bien dommage.

Mais ce n'est pas forcément un problème si le pare-feu est correctement configuré (secondé par un profil d'accès si nécessité de restreindre encore plus certains services). Quelle est la surface d'exposition du proxy inversé sur internet ?

Posté(e)

@dadoupipo

Bonjour,

Sauf erreur de ma part ( @PiwiLAbruti me corrigera au besoin), quand on utilise un reverse proxy on accède normalement à celui-ci depuis l'extérieur via une URL de la forme https://service.ndd.tld (sous entendu en standard via le port 443 mais cela peut-être un autre port !) sachant que ndd.tl pointe sur @IPexterne du NAS RP.

Donc il faut déjà connaitre l'existance de ce domaine pour atteindre le NAS RP (c'est ce domaine que tu communiques normalement à tes amis, non ?),  et une URL du type https://@IPexterne:443 ne rentrera pas dans le reverse proxy et ne sera pas traitée par le frontend de celui-ci. Justement c'est le frontend du RP qui en fonction du service indiqué dans l'URL de connexion externe, va solliciter le backend du RP qui lui va aiguiller le flux entrant vers le bon service indiqué dans la règle de RP :

  • Si le service est local au NAS qui supporte le RP alors l'@IP de destination (dans la règle du RP) est du type http://localhost:portduService ou http://@IPNASsupportRP:portduService.
  • Si le service est sur une autre machine du réseau local ou une machine distante alors l'@IP de destination (dans la règle du RP) est du type http://@IPmachineLocale:portduService ou http://@IPmachineDistante:portduService.

Au final, si tu as correctement configuré le pare-feu de ton NAS applicatif pour accepter l'@IP du NAS RP et/ou mis en liste blanche l'@IP du NAS RP, il n'y a pas de raisons que ton NAS applicatif bloque l'@IP du NAS RP.

Cordialement

oracle7😉

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.