Virtualiser IPCop

[betienne]

Bonjour à tous,

Si vous voulez virtualiser IPCop avec Qemu j'ai rédigé ça :

http://www.systemx.fr/linux/virtualisat ... tml#item12

Je ne l'ai pas fait avec KVM car il est rare que sur une passerelle on ait une CPU avec les extensions de virtualisation hardware. En Intel c'est encore assez cher, plus économique en AMD 64

Enfin pour ceux que la ligne de commande rebute il y a le package "qemu-laucher" (Debian) avec lequel vous ferez la même chose mais au moins vous saurez ce qu'il y a "derrière le rideau".

pour la virtualisation du réseau avec VDE attendez un peu j'y travaille.

Bon travail à tous.

[jdh]

Même si cette documentation est intéressante et plutôt argumentée, il faut faire TRES ATTENTION à la virtualisation.

La virtualisation peut être très intéressante pour tester un système, encore qu'elle complique la perception des réalités réseaux et c'est justement très délicat avec un firewall !

La virtualisation est très efficace avec des serveurs plus élémentaires : serveurs de mails, serveurs web, serveurs de partage fichiers, serveurs dns, ...

Elle doit être évitée pour des serveurs à pattes multiples : firewall !

Elle doit être évitée pour virtualiser des serveurs situés logiquement sur des zones différentes ! (règle de sécurité obligatoire)


CE N'EST PAS PARCE QUE C'EST POSSIBLE, qu'il faut le faire !


Je déconseille, dans la pratique et en entreprise, d'avoir un host de virtualisation à plusieurs pattes !

En milieu pro, il est bien préférable d'acheter 2 PC neufs et de base et de monter un cluster de firewall (très aisé avec pfSense) que d'utiliser un serveur rack 1U avec QuadCore virtualisé pour faire firewall + toute la DMZ (et sans même compter la très probable difficulté avec les drivers !)

Si l'entreprise n'est pas capable de mettre 250€ dans un pc neuf (basic) pour faire un firewall, alors il y aura bien d'autres problèmes ...

[ccnet]

La virtualisation est utile. Dans le cas d'ipcop (ou den'importe quel firewall) elle ne peut être que restreinte à des situations de test.

Je confirme que la perception de la configuration réseau réel est très souvent perturbée, quand elle n'échappe pas à son utilisateur.

En plus des flux des vm elle même il en existe dans le cas de Vmware ESX bien d'autres propres à l'hyerviseur et à sa gestion. Cela complique les questions de sécurité

En production on ne devrait pas mélanger des machines virtuelles appartenant à des zones de confiance différentes sur une même machine physique.

Ne pas perdre de vue que les sorties d'isolation sont possible sur ESXi. Même si jusqu'à lors ce n'est pas simple à provoquer même en présence d'une faille avérée.

Vmware Esx est sans doute la solution la plus aboutie à ce jour et la plus sûre. Ne parlons des serveurs Vmware ou autre monté sur un autre OS. L'empilement des couches logiciels devient délirant.

[betienne]

Bonjour à tous,

C'est vrai que la possibilité d'exploitation d'une faille autorisant la sortie d'isolation est possible ... Mais avec de bons vieux produits comme Qemu ça n'a pas l'air d'actualité. Si vous avez des infos sur ce genre d'exploit ?

Le vrai risque est de mal configurer le routage sur le système hôte et donc d'autoriser le contournement d'IPCop.

Personnellement j'ai installé chez plusieurs clients un petit serveur genre MSI en boitier mini ATX avec 4Go de RAM, 2 HDD en miroir (le tout moins de 400€) avec IPCop (+snort, guardian, bot, layer 7) ainsi qu'un proxy, un HAVP, un DNS et jusqu'à présent personne ne s'est plaint.

Bien sûr vous me direz que je ne vois peut être pas les problèmes et que la sécurité est illusoire, qui le sait ?

Enfin au lieu de vendre du matos on vend ses propres heures ...

Bon travail à tous.

[jdh]

Ce qui compte en sécurité, c'est de ne pas se mettre dans une situation où on ne sait pas ce qui se passe !

C'est le cas de virtualisation : l'hôte est là, en bas, à la cave, et c'est lui qui dispatche les paquets à la bonne VM. Que savez vous de ce dispatch ? Rien ! Est on en droit de se demander s'il y a des paquets qui n'arrive pas à la VM voulue ou, pire, qui sont fournit à une autre VM ? Est on en droit de se demander s'il y a des exploits au niveau de l'hôte ? Ce qui est certain, c'est que si l'hôte est compromis, toutes les VM sont compromises ! Et je ne parle que de paquets, on pourrait parler d'accès de VM à VM par la mémoire !

C'est le cas de l'intrusion ou le fameux Snort : les ressources (le temps et l'expertise) ne sont RAREMENT là pour tirer profit de ce type d'outil. Et de plus, il est fort mal placé sur un firewall ! Vendre Snort à une pme c'est comme lui promettre qu'elle n'aura jamais de virus : une escroquerie intellectuelle ! Le plus incroyable c'est que cela part d'une bonne idée, mais c'est une fausse bonne idée. Et pire, cela donne le plus grand risque en terme de sécurité : se croire en sécurité : l'outil c'est important, savoir s'en servir est bien plus important ! Je ne crois pas à l'utilité de Snort dans de petites structures, d'abord parce qu'il n'y a pas les ressources.


Ce qui me gène, c'est que les techniques les plus utiles ne sont que rarement mises en place (au profit des celles inutiles ou plutôt moins utiles) : le cluster de firewall, le serveur de log externe, le proxy séparé du firewall, la sécurisation des flux (seul le dns a droit de sortir en dns, seul le proxy a droit de faire de l'http, ...), les dobles lignes, ...

Et puis, le firewall n'est il pas la belle balise bien repérable sur Internet ouverte à toutes les tentatives ?

Firewall, panacée universelle comme le sirop Typhon ! Alors que les portables des utilisateurs sortent de l'entreprise et rentrent le lendemain sans que le firewall y puissent quoi que ce soit.

Ai je besoin de parler de ces utilisateurs qui sont administrateurs locaux de leurs postes ?


La sécurité c'est bien mais ce doit être ADAPTEE : quand on en fait trop, on fait mal.

[ccnet]

Ce qui compte en sécurité, c'est de ne pas se mettre dans une situation où on ne sait pas ce qui se passe !

C'est clairement la pire des situations.