Freebox V5 ADSL

Question : à quoi sert, ou servira, ce service apache sur la freebox ?
> c’est la page de conf d’usine du routeur, bloquée à l’accès ? (erreur 403).

Il permet de télécharger la playlist pour le multiposte, et espérons plus un jour

Ok et pourquoi répond t’il depuis lorsque la source est le réseau local et la destination est l’interface publique :/ là est un problème !

+1, j’ai du router les ports 80 et 443 pour que la DMZ les voit...

Re, alors un problème un peu embettant vis à vis de ce bug : à cause du Port Forwarding sur la freebox, un firewall tel que iptables ne peut pas voir la véritable ip source d’un packet :( donc impossible d’implémenter une sécurité basée sur la source d’une requete :/ c’est quand même très gênant (la source sur les ports explicitement forwardés est bien évidemment la freebox .. logique ...)

J’ai moi aussi rencontré ce problème embetant, j’ai pas mal de port forwarder pour regler ca, et en plus de ca j’utilise le fichier host pour resoudre les noms correspondant a mes machines local par leur adresse local, mais j’avoue que c’est assez chiant a tenir a jour, a cause de ce bug :( Sinon une autre solution, si on a trop de machine, ca serai 2 serveur DNS, un serveur pour les resolutions locales (avec les IP locals) et un pour les resolutions externes... En supposant qu’on utilise des noms de domaines, et tout ca juste pour eviter de passer par la freebox et se retrouver face a son bug :( J’espère que free réagira et corrrigera ce bug.

Je confirme le problème et c’est plutôt gênant...
J’ai un fixe que je voulais mettre en serveur sur la DMZ et un portable. Je ne peux donc pas définir un alias dans le fichier hosts du portable pour accéder à l’adresse locale du serveur, vu que ça ne marchera plus de l’extérieur...
Et si je ne peux tester mon serveur (et ses éventuelles failles) du réseau local comme il est vu de l’extérieur, il n’y a aucun intérêt, et il est même “dangereux” de le mettre en DMZ... Dommage.

Et apparemment, Free ne semble pas réagir sur ce problème vu que ça fait plus de 7 mois qu’il a été ouvert...

“De plus le port 80 répond et c’est un service apache (renommé cheyenne) présent sur la freebox ! C’est une belle faille de sécurité étant donné que même la version de apache est affichée.”

Pourquoi est-ce une faille?

“(la source sur les ports explicitement forwardés est bien évidemment la freebox .. logique ...)”

Pardon? Quelle idée!

“J’ai moi aussi rencontré ce problème embetant, j’ai pas mal de port forwarder pour regler ca, et en plus de ca j’utilise le fichier host pour resoudre les noms correspondant a mes machines local par leur adresse local, mais j’avoue que c’est assez chiant a tenir a jour, a cause de ce bug :(”

Je ne comprends pas! De quoi s’agit-il?

“Et si je ne peux tester mon serveur (et ses éventuelles failles) du réseau local comme il est vu de l’extérieur, il n’y a aucun intérêt, et il est même “dangereux” de le mettre en DMZ... Dommage.”

Bien sûr que si on peut, je ne vois pas du tout le rapport avec les redirections!

“De plus le port 80 répond et c’est un service apache (renommé cheyenne) présent sur la freebox ! C’est une belle faille de sécurité étant donné que même la version de apache est affichée.”

Pourquoi est-ce une faille?

s’en est potentiellement une ... en connaissant la version de l’apache qui tourne, s’il n’est pas mis à jour régulièrement, on peut essayer d’utiliser une faille connue de la version installé sur la freebox pour ... faire le mal à la freebox. en règle générale quand on à un serveur Web, on rajoute l’option ServerSignature off pour éviter cette faille

“(la source sur les ports explicitement forwardés est bien évidemment la freebox .. logique ...)”

Pardon? Quelle idée!

et si, si tu forward un port explicitement, alors une personne qui vient du net passe par la règle de NAT, le packet naté arrive sur le serveur ... a forciori ... avec l’ip interne de la freebox (192.168.0.254) au lieu de l’IP d’origine. c’est ça le NAT (ou PAT ici plutôt mais c’est pareil)

“J’ai moi aussi rencontré ce problème embetant, j’ai pas mal de port forwarder pour regler ca, et en plus de ca j’utilise le fichier host pour resoudre les noms correspondant a mes machines local par leur adresse local, mais j’avoue que c’est assez chiant a tenir a jour, a cause de ce bug :(”

Je ne comprends pas! De quoi s’agit-il?

ta freebox, tu la mets en routeur, avec un réseau interne en 192.168.0.0/24.
»> ton serveur, tu le met en 192.168.0.1 et en ip DMZ (par exemple)
»> tu fais un serveur web avec 2 vitrualhost toto.mondomaine.com et titi.mondomaine.com (correspondant à l’ip publique de ta freebox 81.82.83.84)
»> depuis internet aucun problème et sur le serveur on reçoit bien les packet avec l’ip source correspondante à l’ip d’origine
»> depuis le réseau 192.168.0.0/24 (donc ta deuxieme machine par exemple) si tu tape toto.mondomaine.com ... tu résouds l’ip publique ... et ça marche pas ! du coup il faut forwarder explicitement les ports pour résoudre le problème

“Et si je ne peux tester mon serveur (et ses éventuelles failles) du réseau local comme il est vu de l’extérieur, il n’y a aucun intérêt, et il est même “dangereux” de le mettre en DMZ... Dommage.”

Bien sûr que si on peut, je ne vois pas du tout le rapport avec les redirections!

heu là je n’ai pas bien compris non plus ...

Bon la solution pour Free c’est de modifier les règles du firewall de la freebox sur le modèle de cette règle iptables :

iptables -A PREROUTING -i “interface_LAN” -s “réseau_interne” -d “ip_pulique” -j DNAT –to “ip_DMZ”

tout ce qui rentre par l’interface LAN ayant pour ip source une ip du réseau interne et ayant pour destination l’ip publique de la freebox sera routé vers l’ip en DMZ ...

c’est quand même pas compliqué Mr FREE !!

“Et si je ne peux tester mon serveur (et ses éventuelles failles) du réseau local comme il est vu de l’extérieur,
» il n’y a aucun intérêt, et il est même “dangereux” de le mettre en DMZ... Dommage.”

Bien sûr que si on peut, je ne vois pas du tout le rapport avec les redirections!

Non, on ne peut pas voir depuis le réseau local le serveur tel qu’il est vu de l’extérieur.
On est obligé, pour avoir un fonctionnement à peu près correct, de bidouiller en local des redirections, que ce soit avec des forwarders ou des fichiers hosts ou toute autre solution trouvée. Mais... Quelle que soit la solution, vu que j’utilise une solution que n’utiliseront pas les personnes “de l’extérieur” pour accéder à mon serveur en DMZ, je ne serais pas, par définition, dans la même configuration que ceux qui pourraient essayer de trouver des failles à mon serveur.

Ce qu’il faudrait, c’est juste que la machine en DMZ soit vue par les machines du réseau local comme une machine d’un réseau à part. C’est normalement le but d’une DMZ, un réseau à part du réseau interne, mais accessible comme toute autre machine du réseau externe...

Est-ce toujours le cas début 2019 ?