IPCop et VMWare, quelques questions... (schéma)

[jackseg]

Bonsoir.
Je vous mets le schéma d'un réseau que j'ai fait, ce sera plus simple pour comprendre mes questions:
http://www.segalla.org/jackseg/site/tel ... reseau.jpg

Tout cela fonctionne parfaitement mais je me pose quelques questions à propos de la sécurité et surtout si c'est fait dans les règles de l'art.
Pour info, le serveur possède 2 cartes réseaux physique et j'ai attribué Vmnet0 à la 1ère carte et Vmnet2 à la seconde.

- Ma crainte est de savoir si il y a un risque à mettre une adresse interne (ici 192.168.2.3) sur la 1ère carte physique qui va directement au modem ADSL alors que la machine virtuelle IPCop utilise du PPPoE.
Je ne sais pas pourquoi, mais quand je ne met pas d'adresse IP sur la carte physique (donc sur la base qui est une Centos et non dans une machine virtuelle), IPCop (en virtuel) n'arrive plus à se connecter sur le modem et je ne comprend pas pourquoi.
- J'aimerait savoir, au niveau de la sécurité, si ce schéma est correct ou pas pour les machines virtuelles qui sont derrière un IPCop virtuel. Y a-t-il des contre-indications à mettre IPCop dans une machine virtuelle ?
- Y aurait-il un autre moyen, peut-être plus élégant ou plus simple de concevoir une architecture proche de celle-ci ?

Je précise encore que mes questions concernent VMWare Server (car j'ai du m'arranger avec un certain budget) et que je ne peut pas passer sous ESX ou autre.

Toutes critiques, bonnes ou mauvaises, sont les bienvenues pour améliorer cette architecture.
Merci d'avance.
Jacques

[jackseg]

Bonjour,
Personne n'a d'idée ?
J'aimerais juste savoir si je dois continuer sur cette structure ou alors revoir quelques points (surtout au niveau de la sécurité) avant.

Jacques

[jdh]

En effet, l'interface qui va vers le routeur ADSL NE DOIT ETRE utilisé QUE par IPCOP. Alors il NE FAUT PAS lui attribuer d'adresse dans le réseau interne (par exemple 10.0.0.1/24).

Fondamentalement, PPPOE n'a pas besoin d'adresse ip sur l'interface ethernet (Red) qui est relié au modem ADSL. IPCOP fixe (fixait ?) l'adresse de Red à 1.1.1.1 dans ce cas parce qu'il lui faut une adresse.

Le mieux eut été de recycler un vieux PC dédié à IPCOP pour éviter toute embrouille avec vmWare. Un vieux PC c'est un PII300 ou 400 avec 128M et un disque 4 ou 6G. C'est pas trop difficile à trouver : il doit bien en trainer un dans un coin ! Avec un proxy (SQUID) et le filtrage qui va avec (SQUIDGUARD avec l'addon de Franck78), 256M sera plus confortable.

Ensuite tu pourras répartir les 2 cartes gigabit du Dell 2900 à l'une ou l'autre instance de virtualisation vmWare. Cela sera plus performant et plus secure.

[jackseg]

Merci de ta réponse.

Alors pour le vieux PC, je l'ai, mais je l'ai utilisé comme serveur de backup (2 disques de 80GB en Raid1 logiciel sous SME).
Il faut que je regarde pour un autre PC mais le but étais d'avoir le maximum de machines dans une seule et comme le Dell 2900 est puissant, je me suis dis qu'un IPCop virtuel serait une bonne solution.

Donc, il n'est pas normal que je soit obligé de mettre cette adresse privé sur la carte réseau qui va au modem. C'est bien ce qu'il me semblait
Mais y a-t-il un risque à ce niveau ? Je ne vois pas comment quelqu'un pourrait en profiter car la personne qui voudra entrer verra en 1er l'IPCop, non ?

Jacques

[jackseg]

Encore une autre petite question.
On m'a dis qu'il étais possible de rediriger le port de TSE (3389) sur le port 22, ce qui ferait que je ne laisse que le port 22 d'ouvert depuis l'externe.
Est-ce possible et si oui, les clients TS arrivent sur l'IPCop via le port 3389 et ensuite IPCop s'arrange pour rediriger tout sur le port 22 ou alors il faut changer le port aussi sur le client ?

Merci.
Jacques

[fabzz007]

oui et non... si tu dédies le port 22 à TSE tu ne pourra faire que du tse avec se port et plus de ssh... par contre via Ssh (22) tu peux faire du tunneling de ports. En claire : lorsque tu te connect via un client ssh (putty) sur ton port 22 tu peux spécifier à ton serveur ssh de rediriger le port 3389 de ton serveur tse (192.168.2.5:3389) sur un port local de ta machine client (5000).

Par exemple avec putty si dans la section tunnel tu ajoute la règle suivante :

L5000 192.168.2.5:3389

Et que ensuite tu t'authentifie correctement sur ton serveur ssh, ton pc client pourra se connecter à ton serveur TSE via 127.0.0.1:5000 il ne se connectera pas à un port local mais à un port tunnellé via ssh sur ton serveur TSE...

J'espère avoir été assez claire

@++


Fabz

[jackseg]

Merci beaucoup pour ta réponse.

Donc, si j'ai bien compris, un client utilisant le remote Desktop Connection de Windows XP ne pourra jamais passer par un autre port que le 3389.
Il faut utiliser cette redirection de port via Putty par exemple, non ? (possibilité de faire du tunneling de ports).

Donc, si c'est comme ça, je laisse tomber, car les clients externes utilisent le client de microsoft et ne vont pas se casser la tête avec Putty ou autre.

A+
Jacques

[fabzz007]

si tu veux mon avis c'est dommage de ne pas utiliser le tunneling dans un cas comme celui là... c'est simple à mettre en place et très simple à "tutorialiser" pour les utilisateurs....

car l'ouverture du port 3389 sur firewall sera la porte ouverte à des attaque par force brute (genre dictionnaire de mot de passe avec compte admin)

alors que si tu paramètre ton serveur ssh avec authentification par certificats et bannissement des ip après 5 echec d'ouverture de session ça me parait plus pro propre et secure

Enfin c'est que mon avis

Sinon tu peux connecter tes utilisateurs distant par vpn

@+++