pfSense casse l'upload de fichier sur Wordpress en LAN
-
Bonjour,
Nous possédons un Netgate XG-7100.
Sur ce pare-feu, nous avons quatre interfaces de configurées:
Interface 1: Lien WAN
Interface 2: Réseau local 1 - 192.168.0.XXX
Interface 3: Réseau local 2 - 192.168.3.XXX
Interface 4: Réseau public - 157.143.XXX.XXXLe réseau public sert à l'hébergement web, et nous avons deux cas de figure lors d'un envoi de fichiers sur un site Wordpress.
Interface 1: Impossibilité d'envoyer un fichier avec le message suivant sur Wordpress:
L’enregistrement de l’image a échoué, probablement car le serveur est occupé ou ne dispose pas d’assez de ressources. Téléverser une image plus petite pourrait aider. La taille maximum recommandée est de 2500 pixels.Le message actuel fait penser à une sorte de time-out, mais nous avons aussi une autre situation avec l'interface 2:
Interface 2: L'image s'envoie correctement sur le site, aucun message d'erreur.
Détails:
Contexte : Milieu professionnel, matériel récent.
Besoin : Régler le problème d’envoi d’une image sur un site Wordpress de l’interface publique à partir de l’interface 1.
WAN (modem/routeur/box) : Le firewall nous sert de routeur, et possède 6 adresses publiques.
LAN : Deux réseaux en 192.168.0.X et 192.168.3.X.
Autres fonctions assignées au pfSense : VPN et routeur.
Pistes imaginées
Blocage du port 443 par le firewall pour les utilisateurs de l’interface 1 lors de l'upload d'une image, alors que la navigation fonctionne.Recherches : Nous avons essayé de modifier les règles de pare-feu, et forcer le passage par le WAN en bloquant l’accès du public depuis le réseau local 1, sans succès.
Logs et tests complément de "Recherches" : Il n’y a eu aucun résultat à nos tests.
-
Il y a une effort de présentation, mais c'est améliorable : cf le fil A LIRE EN PREMIER.
Votre description est incomplète et laisse des inconnues :
- le serveur comportant un site sous Wordpress est sur Internet ou interne (dans une DMZ) ? J'ignore
- 2 interfaces comporte des adresses ip publiques : WAN et interface 4, en outre vous avez 6 adresses publiques : ce n'est pas clair
Avez vous 2 interfaces WAN ? (une avec 5 adresses ip publiques et 1 avec 1 seule ip publique ?)
Avez vous une zone DMZ ? (Avec un serveur Wordpress hébergé, cela semble assez indispensable, compte tenu des risques ...)
L'hébergement d'un site web, d'un serveur ftp, ou la réception des mails, est un facteur de risque important pour une entreprise : il faut être très prudent. (C'est mon métier.)
-
This post is deleted! -
@jdh Merci pour votre mise en garde, mais l'hébergement est aussi notre métier.
Nous avons quatre interfaces effectives:
Interface 1 --> Sortie internet, adresse IP publique en 88.xx.xx.xx
Interface 2 --> Lan 1, adresse en 192.168.0.XX
Interface 3 --> Lan 2 adresse en 192.168.3.XX
Interface 4 --> Réseau public, adresse en 157.XX.XX.XX/29 pas de NAT(Je le reposte, parce que je ne peux pas éditer le message)
-
Vous n'avez pas répondu complètement, mais votre WordPress doit être interne.
Je ne comprends pas la différence entre Interface 1 et Interface 4 : il y a 20 ans, je faisais l'erreur de créer une DMZ en utilisant des adresses ip publiques (et perdant au passage des ip, par découpage d'un /29). Le bon schéma est toujours d'avoir une DMZ en adressage privé et de réaliser un NAT (en ipv4) : l'opération de NAT n'ajoute pas de latence quand le firewall analyse ces paquets !
Il serait judicieux de vérifier le MTU de chaque interface WAN : s'il est différent, le mieux serait de fixer le MTU du pfSense à la valeur minimale des 2. (Je n'aime pas beaucoup bricoler le MTU, mais cela pourrait être une explication de différence).
Wordpress étant devenu le n° 1 des cms, il est aussi probablement le plus visé par les exploits. Il me semble très logique, outre la dmz, d'insérer un Reverse Proxy dument sécurisé (mod_secure, vulture, ...)
-
@jdh Bonjour,
Merci pour votre réponse, mais l'avantage, et non des moindres d'avoir un rang d'ip publique, est de pouvoir héberger plusieurs serveurs donnant le même service. Lais là n'est pas le problème, si vous aimez faire du NAT ne vous genez pas.
Nous utilisons déjà un reverse proxy avec nginx et le mod secure dessus, mais encore une fois, là n'est pas le problème.
Effectivement changer les valeur de la MTU a été envisagé, mais je n'aime pas trop bouger ce paramètre.
Lorsque je regarde les logs du pfSense au moment du blocage, j'ai un deny sur le port 443 avec TCP:RA et une erreur http 499 au niveau du serveur (time out) ce qui est logique puisque le pfSense bloque.