La redirection de port m'ouvre une porte
-
Mon réseau local utilise des adresses IP publiques (qui m'appartiennent). A.B.C.35 est une adresse publique. A.B.D.2 est une adresse publique.
Le client SSH sur Internet se connecte à A.B.D.2 sur le port 22222
A.B.C.35 écoute sur le port 22.
A.B.C.2 n'écoute pas sur le port 22222, cette adresse sert juste de destination pour le client SSH, en quelque sorte une adresse IP virtuelle. Les paquets à destination de A.B.D.2/22222 seront translatés sur le PfSense est arriveront sur A.B.C.35/22Je souhaite me connecter à A.B.C.35 non pas directement mais en utilisant une adresse de la DMZ (je ne veux que soit visible depuis Internet que les adresses de ma DMZ, et A.B.C.35 sera à terme un adresse privée). J'utilise le port 22222 et non pas le port 22 puisque mon serveur A.B.D.2 en DMZ a lui aussi un service SSH en route.
Merci de votre aide.
-
En résumant de façon concise, vous souhaitez accéder depuis internet à un serveur SSH situé dans le lan par l'intermédiaire d'un serveur situé en dmz. Fort logiquement vous le voulez pas que l'ip du serveur ssh en lan soit visible depuis l'extérieur. Est ce bien cela ?
La trafic ssh venant de l'extérieur transitant par la machine en dmz (A.B.D.2) avant d'arriver sur le serveur ssh du lan (A.B.C.35). -
Oui sauf la fin, un petit détail : le traffic ne transite pas par la machine en DMZ, le firewall faisant la redirection avant (translation d'adresse destination et de port destination). Mais sinon, oui c'est bien cela.
-
La machine en dmz ne sert à rien dans votre besoin d'accès ssh ?
Vous avez juste besoin d'un accès ssh à la machine situé dans le lan ?J'ai donc rajouté une règle sur le PfSense qui dit que les paquets a destination de A.B.D.2 sur le port 22222 doivent aller sur A.B.C.35 sur le port 22.
J'ai beau relire cette phrase depuis hier, je ne comprend pas en quoi A.B.D.2 est impliqué puisque vous ne souhaitez pas y accéder.
-
Oui, j'ai juste besoin d'un accès ssh au serveur du LAN.
A.B.D.2 est juste impliqué parce que j'ai besoin d'une adresse IP publique visible depuis internet, le client SSH doit avoir une adresse sur laquelle se connecter, cette adresse ne devant pas être l'adresse IP publique du serveur LAN car je veux faire comme si mon réseau LAN était en adressage privé.
En fait, j'aurais un réseau LAN en adressage privé, j'aurais moins de problème car personne ne pourrait joindre directement mon serveur interne, non pas parce que le firewall le bloquerait mais parce que cette adresse ne serait pas routée sur internet. Ce qui n'est pas forcément totalement secure.
-
Oui, j'ai juste besoin d'un accès ssh au serveur du LAN.
A.B.D.2 est juste impliqué parce que j'ai besoin d'une adresse IP publique visible depuis internet, le client SSH doit avoir une adresse sur laquelle se connecter, cette adresse ne devant pas être l'adresse IP publique du serveur LAN car je veux faire comme si mon réseau LAN était en adressage privé.
C'est un non sens total et une profonde incompréhension. Et Pfsense ou autre n'y change rien. Il n'est pas nécessaire d'avoir en dmz (ou ailleurs) une machine avec une ip publique pour pouvoir utiliser cette ip publique à la seule fin d'atteindre une autre machine dont on veut cacher l'adresse. De plus cacher n'est pas sécuriser, ni l'inverse. Même chose pour le NAT.
Il y a de multiples solutions, mais en premier lieu au moins celle-ci qui, a priori, minimise les changements.
Utiliser une dmz en bridge avec Wan, y placer le serveur ssh et fillter correctement. Pas de nat, pas de changement du plan d'adressage. Utiliser son ip publique pour y accéder sans compromettre le lan.Sinon :
Si vous avez un stock d'ips disponibles vous pouvez aussi en utiliser une disponible pour créer une ip virtuelle qui vous pourriez ensuite translater vers l'ip que vous voulez cacher. Vous pouvez vous inspirer de http://gugus69.free.fr/special_nat_configuration_with_pfsense.php Je n'en raffole pas mais c'est toujours possible.
Voir aussi http://www.digitalphotomac.com/projects/PFSense/virtualip_nat.htmlEt tant que j'y pense :
En fait, j'aurais un réseau LAN en adressage privé, j'aurais moins de problème car personne ne pourrait joindre directement mon serveur interne, non pas parce que le firewall le bloquerait mais parce que cette adresse ne serait pas routée sur internet
Dès lors que vous avez du nat c'est une pure vue de l'esprit.
-
C'est un non sens total et une profonde incompréhension. Et Pfsense ou autre n'y change rien. Il n'est pas nécessaire d'avoir en dmz (ou ailleurs) une machine avec une ip publique pour pouvoir utiliser cette ip publique à la seule fin d'atteindre une autre machine dont on veut cacher l'adresse
Pas du tout. D'un, je n'ai pas mis la machine avec une ip publique en DMZ pour pouvoir utiliser cette ip publique à la seule fin d'atteindre une autre machine, c'est juste que j'avais besoin d'une adresse IP publique pour pouvoir l'utiliser comme adresse IP virtuelle pour mon serveur dans le LAN. Ma DMZ ne comporte que 5 adresses (je n'y peux rien, c'est la vie), si je peux utiliser une adresse IP déjà utilisée mais dont le port est libre, alors je le fais, je ne vois rien de mal dedans.De plus cacher n'est pas sécuriser, ni l'inverse. Même chose pour le NAT.
Je ne cache pas, je veux seulement faire comme si mon serveur dans le LAN n'était pas directement joigneable depuis Internet (faire comme si mon LAN en IP publique utilisait des adresses IP privées, ce qui m'aidera le jour où je migrerais réellement mon LAN en adressage privé).Je ne veux pas mettre mon serveur en DMZ, il en est hors de question puisqu'il héberge des services intranet. Ce serveur possède hormis les services intranet un serveur web et un serveur ssh. J'utilises le serveur SSH pour alimenter le serveur web qui n'est pas directement joigneable depuis Internet mais à travers un reverse-proxy apache (mod_proxy) hébergé sur un serveur en DMZ (en l'occurence A.B.D.2 mais ça n'a pas d'importance).
La solution que j'ai trouvé est d'installer un proxy SSH sur un serveur en DMZ. Je voulais une solution utilisant simplement des règles de filtrage, sans logiciel, mais ça n'a pas l'air d'aller.
Dès lors que vous avez du nat c'est une pure vue de l'esprit.
En fait, je pense que je viens de comprendre : je n'ai pas mis encore de NAT en place sur le PfSense. C'est peut-être là mon problème. Sauf que je vais avoir du mal à le résoudre puisque je ne peux pas encore mettre de NAT car j'ai besoin de parler avec d'autres réseaux distants sans NAT (et la solution de mettre en place un VPN n'est pas une solution immédiate même si c'est une bonne solution, car il me faudrait plusieurs mois pour la mettre en place (je ne maîtrise pas les réseaux distants)). Bref, le proxy SSH (sshproxy par exemple) pourrait résoudre mon problème. -
si je peux utiliser une adresse IP déjà utilisée mais dont le port est libre, alors je le fais, je ne vois rien de mal dedans.
Si l'on utilise le transfert de port c'est bien pour faire les choses proprement. Ce n'est pas sérieux.Je ne veux pas mettre mon serveur en DMZ, il en est hors de question puisqu'il héberge des services intranet.
Confusion totale encore. Ce n'est pas parce qu'un serveur est utilisé depuis le réseau interne qu'il n'est pas mis en dmz. J'irai même plus loin. Tous les serveurs d'un réseau devrait se trouver dans une dmz spécifique, même si ils ne délivrent que des services intranet. Il n' y aucune raison que les utilisateurs puissent accéder à autre chose que l'application qui les concerne. Il n'est pas rare , dans les structures un peu étoffées, de trouver 2 dmz, une interne, l'autre externe. Les serveurs web par exemple sont en dmz externe, comme les relais de mesagerie, alors que le serveur de messagerie est en dmz interne, par exemple.La règle de base est simple : accès externe direct sur un serveur -> placement en dmz.
Sinon ssh via proxy c'est correct.
Sauf que je vais avoir du mal à le résoudre puisque je ne peux pas encore mettre de NAT car j'ai besoin de parler avec d'autres réseaux distants sans NAT
Je ne comprend pas. Communiquer avec un système distant c'est d'abord un problème de routage. Le Nat n'empêche pas de communiquer avec un réseau distant. A l'exception de quelques protocoles spécifiques.
-
Je ne comprend pas. Communiquer avec un système distant c'est d'abord un problème de routage. Le Nat n'empêche pas de communiquer avec un réseau distant. A l'exception de quelques protocoles spécifiques.
La réponse est dans la phrase, vers la fin. Je communique avec des réseaux distants avec des protocoles qui n'aiment pas le NAT.
Confusion totale encore. Ce n'est pas parce qu'un serveur est utilisé depuis le réseau interne qu'il n'est pas mis en dmz. J'irai même plus loin. Tous les serveurs d'un réseau devrait se trouver dans une dmz spécifique, même si ils ne délivrent que des services intranet. Il n' y aucune raison que les utilisateurs puissent accéder à autre chose que l'application qui les concerne. Il n'est pas rare , dans les structures un peu étoffées, de trouver 2 dmz, une interne, l'autre externe. Les serveurs web par exemple sont en dmz externe, comme les relais de mesagerie, alors que le serveur de messagerie est en dmz interne, par exemple.
La règle de base est simple : accès externe direct sur un serveur -> placement en dmz.
Il n'y a toujours pas de confusion, et encore moins totale : il n'y a pas de règles universelles, chaque réseau est différent, à une histoire, est conçue d'une façon ou d'une autre. Le coup de la DMZ interne n'est pas forcément obligatoire, même si ce n'est pas une mauvaise solution, un vlan spécifique est toujours possible (vlan filtrant bien entendu). Personnellement, je vois une DMZ non pas comme un fourre-tout de serveur mais comme un étape entre le réseau externe et le réseau interne. Je pense qu'une DMZ ne doit contenir que le strict minimum, que ce qui est visible depuis l'Internet. La DMZ ne devrait contenir aucunes données, aucunes informations sensibles, car si un serveur en DMZ est corrompu, le risque pour les autres est nettement plus grand, donc le vol de données avec : le but étant que si un serveur de la DMZ est corrompu, l'attaquant n'ait accès qu'au serveur corrompu, qu'il ne puisse pas propager son attaque facilement. Nous avons donc deux conceptions de la DMZ différentes, la mienne et la votre n'étant pas stupides.
-
Je communique avec des réseaux distants avec des protocoles qui n'aiment pas le NAT
Donnez des exemples cela intéresse tout le monde.
Il n' y a pas de "coup de la DMZ interne", si on doit protéger des données, des serveurs, on les place dans ce type de zone.
1. La majorité des vols de données est le fait d'utilisateurs internes.
2. Une dmz est un endroit où l'on confine des machines et des services justement parce qu'ils sont sensibles.
3. On sait parfaitement isoler des serveurs d'un même sous réseau dans une même dmz pour empêcher qu'une machine compromise ne soit exploitée pour en atteindre une autre.
-
Donnez des exemples cela intéresse tout le monde.
La réplication Active Directory il me semble.
-
A confirmer si tel est le cas c'est important de le savoir.
-
La replication de domaine Active Directory utilise RPC qui utilise des ports dynamiques (le serveur appelé doit il me semble rappeler l'appelant sur un autre port, ce qui pose problème avec du NAT)
http://www.microsoft.com/france/technet/produits/win2000s/adrepfir.mspx#EO
-
Bien que n'ayant pas eu à faire à ce type d'environnement dernièrement, il me semble que tout cela est documenté chez Ms dans ce document : http://www.microsoft.com/downloads/details.aspx?FamilyID=c2ef3846-43f0-4caf-9767-a9166368434e&displaylang=en
-
Le document explique comment mettre en place IPsec pour permettre la réplication Active Directory en traversant des firewalls.
Un de mes problèmes est que le NAT me gêne pour la replication Active Directory est que je ne peux pas mettre en place d'autres solutions car je ne maîtrise qu'un site parmi une dizaine, et que la mise en place d'un VPN inter-site mettrait des mois, plusieurs mois.
Mon problème initial de port ouvert ne peut être simplement résolu, car en tirant la ficelle de la résolution, on pêche une série de problèmes. Un proxy ssh est pour moi la solution la plus simple sans trop de changement.