Zone Bleue vers Zone Verte - Partage SMB impossible

[JarodOnTheNet]

Bonsoir à toutes et à tous,

J'essaye de passer au crible IpCop Version 1.4.18 (upgrade de la version 1.4.11 à 1.4.18) dans le but d'établir une base de connaissance sur ce firewall.

Le but est donc de se passer, au premier abord au maximum de tout addons et donc de se passer dans une premier temps de Block Out Traffic. Mon but est d'abord la recherche maximale de la sécurité du produit en évitant les failles de sécurité potentielles des addons. Je compte ensuite ajouter Block Out Traffic et Zerina pour les accès VPN.

Voici la config du labo de test :

1 IPCop avec 4 interfaces : Vert, Bleu, Route et Orange

Adressage des segments :
================

Vert : 192.168.2.0/24 - DG 192.168.2.2 (Ipcop) - DNS : 192.168.2.253/24 Windows 2000 Natif
Bleu : 192.168.3.0/34 - DG 192.168.3.2 (Ipcop) - DNS : 192.168.3.2
Rouge : 192.168.65.0/24 - DG 192.168.65.2 (Ipcop) - DNS : 192.168.65.2
Orange : 192.168.4.0/24 - DG 192.168.4.2 (Ipcop) - DNS : 192.168.4.2

Le but du labo est de segmenter plusieurs types de machines potentiellement dangereuses :

- Des machines présumées infectées devant être désinfectées (en sous interface vlan de la verte)
- Des machines publiques filaires ayant accès à Internet (DMZ ou dans un Vlan en sous interface vert)
- Des machines publiques devant être accessible via Internet (DMZ)
- Des machines de notre réseau d'entreprise (Zone Verte)
- Des machines wireless (portables) devant accéder aux ressources de notre entreprise (Zone Verte)

Tous les points énoncés ci-dessus ont été résolus par l'emploi du transfert de port et via la définition de règles adéquates de la dmz (bleu vers Vert) et via des règles d'accès à bleu.

LE PROBLEME :
=========

Le seul problème restant est l'exploitation du partage de fichier MicroSoft de la zone bleue à la zone verte uniquement pour voir les machines et leurs partages via le protocole NetBios. En effet, un portable Wireless étant par définition dangereux pour le réseau vert, le placer dans la zone bleue semble la meilleure solution mais malheureusement, IL EST INTEGRE DANS LE DOMAINE WINDOWS EXPLOITE et le déplacer l'isole forcément. De plus, j'utilise ce portable et Outlook mais dont le fichier .pst est situé sur le serveur contrôleur de domaine, ainsi que mon répertoire "Mes Documents".

Vous comprendrez donc mon problème ...


Des telnet established sont réussis sur tous les ports suivants :

- 139, 445, 389, 53, 88, 135, 1026, 123

Des telnet échoués ne sont à constater que sur les ports NetBios 137 et 138 qui pour moi sont inutilisé.

A mon sens, seul le port 139 Netbios est réellement utilisé suite à l'enregistrement du trafic d'une machine vers une autre sur le même segment.

Dans les logs d'Ipcop subsiste seul le refus d'une connexion utilisant le protocole ICMP

Adresse source : 192.168.3.8
Adresse destination : 192.168.2.253 (DC MicroSoft 2000 Natif)
Port source : ICMP
Port destination : ICMP

De temps à autre, curieusement le port 53 mais pas systématiquement, un nslookup protheus (192.168.2.253) renvoyant bien l'adresse IP et un nslookup 192.168.2.253 renvoyant bien le nom pleinement qualifié de notre DC.

Après de nombreuses recherche, j'ai trouvé sur le site de MicroSoft une explication disant ceci :

Pour qu'Active Directory fonctionne correctement à travers un pare-feu, le protocole ICMP (Internet Control Message Protocol) doit être autorisé à travers le pare-feu à partir des clients vers les contrôleurs de domaine pour que les clients puissent recevoir des informations concernant la Stratégie de groupe.

Le protocole ICMP permet de déterminer si le lien est lent ou rapide. C'est un protocole légitime qu'Active Directory utilise pour la détection de Stratégie de groupe et pour la détection de l'unité de transfert maximale (MTU, Maximum Transfer Unit). Le redirecteur Windows utilise également le protocole ICMP pour vérifier qu'une adresse IP du serveur est résolue par le service DNS avant qu'une connexion ne soit effectuée.

Si vous souhaitez réduire le trafic ICMP, vous pouvez utiliser la règle de pare-feu de l'exemple suivant :
<any> ICMP -> DC IP addr = allow

Contrairement aux couches de protocole TCP et UDP, ICMP n'a pas de numéro de port. La raison est qu'ICMP est hébergé directement par la couche IP.

Laisser passer NetBios à travers IpCop n’est donc pas une mince affaire. La difficulté réside en ces termes expliqués par MicroSoft sachant que par défaut un PC1 dans la zone bleue ne voit pas PC2 dans la zone verte ou tout autre zone d’ailleurs.

Alors, avant d'installer Block Out Traffic, existe t'il une solution permettant d'autoriser tout le dialogue ICMP ente la zone bleue et verte à l'exception de l'echo request, equo reply ?

Sinon, il semble qu'il me reste 2 autres solutions :

- Etablir un VPN de la zone Bleue vers la Verte et faire tout passer dans ce dernier
- Créer des vlans en sous interface de la zone Verte et y mettre mon portable pour éviter la zone bleue,
mais je n'aurai pas la même protection

Je suis bien entendu ouvert à toutes alternatives et propositions allant dans la même philosophie.

Si des experts d'IpCop ont des idées ?

D'avance merci

JarodOnTheNet

[JarodOnTheNet]

Bonjour à toutes et à tous,

J'ai l'impression que mon problème donne mal à la tête en voyant les premières lectures et les non-réponses.

Nativement, IpCop bloque ICMP et c'est bien çà qui m'ennuie. ICMP est un protocole important sous jacent à la couche transport et aide finalement en offrant ses services les protocoles TCP et UDP.

Comme je ne suis pas un expert Linux, quelqu'un peut il me dire les commandes qui vont bien pour :

- Autoriser tout ICMP
- Mais bloquer echo request
- Mais bloquer echo reply

Au niveau du filtrage bien sûr car via l'interface graphique, sans Block Out Traffic, c'est impossible vu qu'il faut préciser un port et que cette notion n'existe pas en couche 3 OSI.

J'aimerai pouvoir quand même garder les fonctionnalités de ping via l'interface de vert vers toutes les zones, etc ... sur les interfaces de l'IpCop.

Et tant qu'à faire, l'inverse :

- Bloquer à nouveau tout ICMP
- autoriser echo request
- autoriser echo reply

Au passage, si quelqu'un peut me recommander un bon tuto d'apprentissage pour Iptable pour qu'en mode ligne, je puisse encore mieux exploiter IpCop.

D'avance merci

[ccnet]

Comme je ne suis pas un expert Linux, quelqu'un peut il me dire les commandes qui vont bien pour :

Rien de spécifique à l'OS. C'est un problème réseau.

Au passage, si quelqu'un peut me recommander un bon tuto d'apprentissage pour Iptable pour qu'en mode ligne, je puisse encore mieux exploiter IpCop.

Là vous faite fausse route. Si Vous devez mettre les mains dans iptable pour exploiter IPCOP c'est qu'IPCOP ne convient pas à votre configuration.

J'ai l'impression que mon problème donne mal à la tête en voyant les premières lectures et les non-réponses.

J'ai surtout l'impression que si vous faisiez ici les recherches qui s'imposent vous auriez déjà la solution à votre problème. Ces questions de visibilité des machines, des partages etc dans un environnement Microsoft on déjà été traité à plusieurs reprises.

[leso]

-Il faudrait regarder du coté du wins pour que tout les partages soient visibles (un serveur en bleu et un en vert synchronisé).

-Par défaut ipcop ne bloque pas les pings . Si tu ping de vert vers bleu ca doit passer mais pas l inverse par défaut.

-Tout est gérable par l interface web, normalement tu n as pas utilisé iptables a la main.

- Il faut utiliser les DMZ pinholes (Accés a la dmz en francais) pour éviter le vpn en zone bleu et forwader les ports standards netbios et dns vers le serveur AD.

-Il reste Blockout traffic mais ca change les politiques par défaut .

[JarodOnTheNet]

-Il faudrait regarder du coté du wins pour que tout les partages soient visibles (un serveur en bleu et un en vert synchronisé).

J'ai un serveur Wins sur le segment Vert, aucun serveur sur le segment bleu et en monter un serait vraiment couteux et hors propos. Rendez-vous compte, 1 serveur MicroSoft pour utiliser 1 portable Wireless dans un segment bleu ! De plus, on peut utiliser DNS en lieu et place de Wins depuis Windows 2000 serveur et des clients 2000 et XP. La machine de test en bleu est sous XP Pro Sp2 et intégrée au domaine. Aucune machine n'utilises NetBios sur TCP et les ressources sont toutes vues de n'importe quelle machine.

-Par défaut ipcop ne bloque pas les pings . Si tu ping de vert vers bleu ca doit passer mais pas l inverse par défaut.

Le ping de vert vers bleu fonctionne bien évidemment, mais pas l'inverse, par défaut. C'est bien là mon problème à mon sens. Lorsque l'on demande les favoris réseaux, des messages ICMP sont préalablement envoyé sur le contrôleur de domaine et comme ils sont initiés de la zone bleue vers la verte, ils ne passent pas. C'est un peu comme si je voulais vous parler et vous demander un service en vous demandant préalablement si vous m'écoutez. Si vous ne répondez pas à ma question "m'écoutez-vous", pourquoi m'échiner à vous demander le service ? La communication s'arrête là et on attend le time out de la requête service qui dit que je ne dispose pas des droits nécessaires ou qu'aucune ressource n'est disponible.

-Tout est gérable par l interface web, normalement tu n as pas utilisé iptables a la main.

Effectivement, je n'ai pas utilisé iptables à la main mais je ne vois que 2 possibilité pour laisser passer des messages ICMP :

- taper des commandes Iptables dont je ne connais pas la syntaxe exacte actuellement
- Installer et configurer Block Out Traffic qui devrait les écrire pour moi par règles graphiques interposées.

- Il faut utiliser les DMZ pinholes (Accés a la dmz en francais) pour éviter le vpn en zone bleu et forwader les ports standards netbios et dns vers le serveur AD.

C'est bien ce que j'ai utilisé, un accès à la DMZ et dis que du Lan bleu vers le Vert il faut laisser passer les ports netbios, dns, kerberos, etc ... comme expliqué en détail dans mon problème. D'ailleurs, j'ai précisé les telnet established sur chaque port testé. Seul 2 ne répondent pas : le port 137 et 138 mais le 139 établi bien la connexion et à ma connaissance, après snif d'une communication entre 2 machines faisant ce type de dialogue, présente sur un même segment, cela le confirme.

La seule alerte dans le log reste d'ailleurs uniquement ICMP, pour moi le paquet envoyé avant la demande de service pour voir si la machine est prête à répondre.


-Il reste Blockout traffic mais ca change les politiques par défaut .

Effectivement, je ne vois pas d'autre alternatives sauf la commande iptable a la main laissant passer tous les messages ICMP à l'exception de l'echo request et l'echo reply (ping)

Qu'en pensez-vous ?

[JarodOnTheNet]

Comme je ne suis pas un expert Linux, quelqu'un peut il me dire les commandes qui vont bien pour :

Rien de spécifique à l'OS. C'est un problème réseau.

Effectivement, c'est bien un problème réseau. Les pré-messages ICMP de disponibilité du serveur AVANT d'initier le service NetBios n'aboutissant pas, le service n'est pas demandé. C'est un peu comme si je vous demandais si vous écoutez avant de vous demander le service, un peu comme pour attirer votre attention. Imaginons que nous ne répondez pas "Oui, je suis prêt à vous écouter", pourquoi m'échiner à vous demander le service ? (ici la liste des ordinateurs et partages offrant des ressources et partages réseaux)

Au passage, si quelqu'un peut me recommander un bon tuto d'apprentissage pour Iptable pour qu'en mode ligne, je puisse encore mieux exploiter IpCop.

Là vous faite fausse route. Si Vous devez mettre les mains dans iptable pour exploiter IPCOP c'est qu'IPCOP ne convient pas à votre configuration.

Pas vraiment d'accord. IpCop segmente bien mon réseau de manière fiable et toutes les redirections de port hormis ce trafic NetBios échoue. Par exemple, les ports pour retirer ou ajouter une machine dans un domaine (dans la zone bleue vers le DC en zone verte) et le bureau distant (du bleu vers le lan vert) fonctionnent. Ceci démontre donc le contraire

J'ai l'impression que mon problème donne mal à la tête en voyant les premières lectures et les non-réponses.

J'ai surtout l'impression que si vous faisiez ici les recherches qui s'imposent vous auriez déjà la solution à votre problème. Ces questions de visibilité des machines, des partages etc dans un environnement Microsoft on déjà été traité à plusieurs reprises.

J'ai bien évidemment avant de m'inscrire sur ce forum cherché en long et en large sur Internet et testé é à mon sens tout ce qui pouvait l'être, cela fait 2 jours que je rame

Je ne suis pas vraiment un Newbie sous IpCop, car j'ai fais un labo réussi avec Block Out Traffic et des Vlans sur un IpCop avec 4 interfaces et 6 segments (2 sous segments de l'interface verte) mais l'idée ici est de se passer d'un maximum d'addons justement pour ne pas ajouter des trous éventuels de sécurité et surtout si on peut s'en passer.

Aussi, je réclame votre indulgence par c'est mon premier post sur ce forum.

Que proposez-vous pour laisser passer les messages ICMP de la zone bleue vers la zone verte tout en laissant désactivé le ping (echo request - et echo reply ? )

Là, je ne vois que 2 solutions :

- la ligne de commande hors interface graphique qui donne la bonne syntaxe iptable dont je ne connais
pas encore les méandre

- L'installation de Block Out Traffic qui va en mode graphique normalement écrire tout çà pour moi et
me rajouter des facilités de groupes d'objets, groupes de services, groupes de protocoles, etc ...

MAIS l'idée de départ est de m'en passer.

Maintenant, je demande peut-être l'impossible et je suis peut-être à une limite de IpCop sans module pour aller si loin.

Aussi, avez-vous s.v.p. des liens expliquant la mise en oeuvre de NetBios dans une zone bleue ne contenant qu'un portable vers une zone verte sur laquelle se trouve un ou plusieurs contrôleur de domaine ?

D'avance merci de votre réponse

[leso]

A mon avis sans BOT se ne sera pas fesable , aprés beaucoup de personne considére qu' installé BOT renforce la sécurité de base d IPcop. Ainsi des forks d'ipcop (endian pour ne pas la citer), l intégre par défaut et personne n en est mécontent. Aprés je n ai pas de solution simple mais ca m étonne beaucoup qu'il y est tant de problème avec un AD en zone verte et un client en bleu surtout du a l'icmp.

Si ca peut aider voici quelques regles de base pour iptables: (non testé):
iptables -A INPUT -p icmp -j ACCEPT
iptables -A FORWARD -p icmp -j ACCEPT
iptables -A OUTPUT -o eth1 -p icmp -j ACCEPT (si eth 1 est blue)
iptables -A OUTPUT -o eth0 -p icmp -j ACCEPT

[Poupou94]

Bonsoir,

Tu dis que les ports 137 et 138 ne servent à rien, c'est possible mais tu peux aussi le vérifier, fait quelques essais avec tcpdump sur IPCop pour voir ce qui essaie de passer.
Autrement ne pas oublier que les partages de disques ou imprimantes netbios ne sont pas routés ni routables, ils utilisent des broadcasts pour s'annoncer ce qui impose comme dit plus haut d'utiliser wins ou plus lourd les fichiers hosts ou lmhosts.
Dernier point BOT ne peut pas être un trou de sécurité, par défaut (il bloque tout). C'est ce que tu vas en faire qui peut le rendre moins sécurisant.

Bonnes fêtes, Pascal.

[JarodOnTheNet]

Bonsoir,

Bonjour,

Tu dis que les ports 137 et 138 ne servent à rien, c'est possible mais tu peux aussi le vérifier, fait quelques essais avec tcpdump sur IPCop pour voir ce qui essaie de passer.

J'ai vérifié avec tcpdump qu'il y a bien des tentatives de contacter mon serveur et je vois bien la requête ARP relayée par IpCop. Je ne trouve rien d'autre d'anormal.

Autrement ne pas oublier que les partages de disques ou imprimantes netbios ne sont pas routés ni routables, ils utilisent des broadcasts pour s'annoncer ce qui impose comme dit plus haut d'utiliser wins ou plus lourd les fichiers hosts ou lmhosts.

Effectivement, après l'étude approfondie du protole SMB ou CIFS, je m'aperçois que le protocole n'est pas conçu pour être routable. IpCop l'illustre bien en signalant la tentative ICMP bloquée et en configurant une autre machine, on voit bien lors d'une tentative de parcours du segment bleu un broadcast qui est bien entendu bloqué par défaut par l'IpCop attendu qu'il est comme les autres routeurs firewall de Broadcast.

Par contre, on peut programmer IpCop (en théorie) pour qu'il propage les broadcasts du segment bleu vers le segment vert ou mieux, uniquement vers le ou les serveurs concernés MAIS MicroSoft décourage fortement cette solution pouvant occasionner de lourdes dégradations des performances du réseau. Sais-tu la ou les commandes permettant de le faire pour que je teste ?

J'ai essayé avec le fichier hosts sur chacune des machines mais sans plus de succès. Par contre, je n'ai pas essayé avec lmhosts mais je n'y crois pas.

Ce qui m'étonne, c'est que peu de personnes semblent avoir ce besoin. Pourtant, à mon sens, il me semblait intéressant de placer des machines wireless dans un segment isolé tout en les laissant accéder aux ressources d'un domaine Windows. Curieusement, cela ne semble pas être le cas.

Je suis encore plus surpris que ce besoin ne soit apparemment pas demandé par les entreprises ayant le soucis d'isoler chaque services en utilisant des vlans qui devront bien à un moment communiquer et donc devoir être routés, donc, tomber dans la même problématique. A croire que dans ce cas, elles mettent un serveur de fichiers par segments ne pouvant offrir que des partages à ces seules machines.

J'en déduis donc 2 hypothèses :

- Les utilisateurs de machines Wireless pour éviter ces désagréments laissent ces machines sur le
segment vert

- Où alors, ils définissent un VPN de l'interface bleue vers la verte pour donner l'illusion que le segment
bleu est sur le segment vert. Cela me semble lourd, très lourd mais bon ... As tu un tuto éprouvé
pour tester le VPN uniquement sous IpCop ?

Dernier point BOT ne peut pas être un trou de sécurité, par défaut (il bloque tout). C'est ce que tu vas en faire qui peut le rendre moins sécurisant.

D'accord et pas en même temps avec toi. D'accord parce que par défaut il bloque tout, mais pas d'accord parce qu'il faut admettre que plus on utilise de programmes, plus on risque d'y trouver des failles de sécurités pour pénétrer un système. IpCop seul sans module addons, si il est suffisant et c'était bien ma préoccupation initiale est plus sûr.

Je vais "quoter" mon premier post avec mes conclusions, car j'ai quand même trouvé comment accéder à ces fichiers. J'espère que ce moyen va donner l'envie ou le besoin à d'autres utilisateurs de plancher sur les derniers points posant problèmes.

Bonnes fêtes, Pascal.

Meilleurs voeux pour 2008 !

[JarodOnTheNet]

:cry:

Bonsoir à toutes et à tous,

J'essaye de passer au crible IpCop Version 1.4.18 (upgrade de la version 1.4.11 à 1.4.18) dans le but d'établir une base de connaissance sur ce firewall.

Le but est donc de se passer, au premier abord au maximum de tout addons et donc de se passer dans une premier temps de Block Out Traffic. Mon but est d'abord la recherche maximale de la sécurité du produit en évitant les failles de sécurité potentielles des addons. Je compte ensuite ajouter Block Out Traffic et Zerina pour les accès VPN.

Voici la config du labo de test :

1 IPCop avec 4 interfaces : Vert, Bleu, Route et Orange

Adressage des segments :
================

Vert : 192.168.2.0/24 - DG 192.168.2.2 (Ipcop) - DNS : 192.168.2.253/24 Windows 2000 Natif
Bleu : 192.168.3.0/34 - DG 192.168.3.2 (Ipcop) - DNS : 192.168.3.2
Rouge : 192.168.65.0/24 - DG 192.168.65.2 (Ipcop) - DNS : 192.168.65.2
Orange : 192.168.4.0/24 - DG 192.168.4.2 (Ipcop) - DNS : 192.168.4.2

Le but du labo est de segmenter plusieurs types de machines potentiellement dangereuses :

- Des machines présumées infectées devant être désinfectées (en sous interface vlan de la verte)
- Des machines publiques filaires ayant accès à Internet (DMZ ou dans un Vlan en sous interface vert)
- Des machines publiques devant être accessible via Internet (DMZ)
- Des machines de notre réseau d'entreprise (Zone Verte)
- Des machines wireless (portables) devant accéder aux ressources de notre entreprise (Zone Verte)

Tous les points énoncés ci-dessus ont été résolus par l'emploi du transfert de port et via la définition de règles adéquates de la dmz (bleu vers Vert) et via des règles d'accès à bleu.

LE PROBLEME :
=========

Le seul problème restant est l'exploitation du partage de fichier MicroSoft de la zone bleue à la zone verte uniquement pour voir les machines et leurs partages via le protocole NetBios. En effet, un portable Wireless étant par définition dangereux pour le réseau vert, le placer dans la zone bleue semble la meilleure solution mais malheureusement, IL EST INTEGRE DANS LE DOMAINE WINDOWS EXPLOITE et le déplacer l'isole forcément. De plus, j'utilise ce portable et Outlook mais dont le fichier .pst est situé sur le serveur contrôleur de domaine, ainsi que mon répertoire "Mes Documents".

Vous comprendrez donc mon problème ...


Des telnet established sont réussis sur tous les ports suivants :

- 139, 445, 389, 53, 88, 135, 1026, 123

Des telnet échoués ne sont à constater que sur les ports NetBios 137 et 138 qui pour moi sont inutilisé.

A mon sens, seul le port 139 Netbios est réellement utilisé suite à l'enregistrement du trafic d'une machine vers une autre sur le même segment.

Dans les logs d'Ipcop subsiste seul le refus d'une connexion utilisant le protocole ICMP

Adresse source : 192.168.3.8
Adresse destination : 192.168.2.253 (DC MicroSoft 2000 Natif)
Port source : ICMP
Port destination : ICMP

De temps à autre, curieusement le port 53 mais pas systématiquement, un nslookup protheus (192.168.2.253) renvoyant bien l'adresse IP et un nslookup 192.168.2.253 renvoyant bien le nom pleinement qualifié de notre DC.

Après de nombreuses recherche, j'ai trouvé sur le site de MicroSoft une explication disant ceci :

Pour qu'Active Directory fonctionne correctement à travers un pare-feu, le protocole ICMP (Internet Control Message Protocol) doit être autorisé à travers le pare-feu à partir des clients vers les contrôleurs de domaine pour que les clients puissent recevoir des informations concernant la Stratégie de groupe.

Le protocole ICMP permet de déterminer si le lien est lent ou rapide. C'est un protocole légitime qu'Active Directory utilise pour la détection de Stratégie de groupe et pour la détection de l'unité de transfert maximale (MTU, Maximum Transfer Unit). Le redirecteur Windows utilise également le protocole ICMP pour vérifier qu'une adresse IP du serveur est résolue par le service DNS avant qu'une connexion ne soit effectuée.

Si vous souhaitez réduire le trafic ICMP, vous pouvez utiliser la règle de pare-feu de l'exemple suivant :
<any> ICMP -> DC IP addr = allow

Contrairement aux couches de protocole TCP et UDP, ICMP n'a pas de numéro de port. La raison est qu'ICMP est hébergé directement par la couche IP.

Laisser passer NetBios à travers IpCop n’est donc pas une mince affaire. La difficulté réside en ces termes expliqués par MicroSoft sachant que par défaut un PC1 dans la zone bleue ne voit pas PC2 dans la zone verte ou tout autre zone d’ailleurs.

Alors, avant d'installer Block Out Traffic, existe t'il une solution permettant d'autoriser tout le dialogue ICMP ente la zone bleue et verte à l'exception de l'echo request, equo reply ?

Sinon, il semble qu'il me reste 2 autres solutions :

- Etablir un VPN de la zone Bleue vers la Verte et faire tout passer dans ce dernier
- Créer des vlans en sous interface de la zone Verte et y mettre mon portable pour éviter la zone bleue,
mais je n'aurai pas la même protection

Je suis bien entendu ouvert à toutes alternatives et propositions allant dans la même philosophie.

Si des experts d'IpCop ont des idées ?

Voici le résultat de mes recherches :

De la zone Bleue ou d’un vlan placé sur une sous-interface de l’interface verte, vous aurez tôt au tard besoin d’utiliser les ressources de votre domaine Windows pour :

- Utiliser Active Directory et donc utiliser les ports 445 (directory service) et 389 (ldap) : ok
- Utiliser le protocole SMB sur les ports 137,138 et 139 (TCP et UDP) : ko

Laisser passer NetBios à travers IpCop n’est pas une mince affaire. La difficulté réside en ces termes expliqués par MicroSoft sachant que par défaut un PC1 dans la zone bleue ne voit pas PC2 dans la zone verte ou toute autre zone d’ailleurs.

Pour qu'Active Directory fonctionne correctement à travers un pare-feu, le protocole ICMP (Internet Control Message Protocol) doit être autorisé à travers le pare-feu à partir des clients vers les contrôleurs de domaine pour que les clients puissent recevoir des informations concernant la Stratégie de groupe.

Le protocole ICMP permet de déterminer si le lien est lent ou rapide. C'est un protocole légitime qu'Active Directory utilise pour la détection de Stratégie de groupe et pour la détection de l'unité de transfert maximale (MTU, Maximum Transfer Unit). Le redirecteur Windows utilise également le protocole ICMP pour vérifier qu'une adresse IP du serveur est résolue par le service DNS avant qu'une connexion ne soit effectuée.

Si vous souhaitez réduire le trafic ICMP, vous pouvez utiliser la règle de pare-feu de l'exemple suivant :
<any> ICMP -> DC IP addr = allow

Contrairement aux couches de protocole TCP et UDP, ICMP n'a pas de numéro de port. La raison est qu'ICMP est hébergé directement par la couche IP.

NetBIOS-NS (Name Service), utilise le port 137 pour découvrir et enregistrer la présence d'hôtes SMB et de groupes de travail.

NetBIOS-DGM (Datagram Service) utilise le port 138 pour envoyer et recevoir des datagrammes, par exemple pour envoyer des données à des utilisateurs au sein d'un groupe de travail.

NetBIOS-SSN (Session Service) utilise le port 139 pour envoyer et recevoir des données lors d'une session de partage de fichiers via SMB.

A l’heure ou j’écris ces lignes, il me reste impossible d’exploiter les ports 137 et 138 ce qui empêche de parcourir le segment vert distant à travers l’IpCop. Toutefois, il est possible d’accéder aux ressources partagées via le port 445 en utilisant des chemins UNC.

Exemple :

Démarrer/exécuter et demander \\nomdeserveur\nomdepartage.

Attention, il est important de vérifier dans un environnement de test que les passerelles de chaque machine est correctement définie.

Maintenant, j'espère qu'il sera possible d'aller plus loin et de permettre l'accès au parcours du réseau en exploitant les ports 137 et 138 mais je n'ai plus grand espoir de le faire sans utiliser un VPN donnant l'illusion que le segment bleu est géographiquement situé sur le segment Vert.

Je vais maintenant installer BOT et voir ce que cela donne. Dès que j'en sais plus, je fais remonter l'info sur ce post.

D'avance merci pour toute aide permettant d'avancer sur ce problème

JarodOnTheNet

[ccnet]

- L'installation de Block Out Traffic qui va en mode graphique normalement écrire tout çà pour moi et
me rajouter des facilités de groupes d'objets, groupes de services, groupes de protocoles, etc ...

MAIS l'idée de départ est de m'en passer.

Je comprend mal l'idée de se passer de ce qui donne la solution et de s'obstiner sur ce qui ne la donne pas, ou difficilement.

Libre à vous maintenant d'ajouter je ne sais combien de lignes dans /etc/rc.d/rc.firewall. Si vous ne maitrisez pas iptables, pour le coup vous pourrez vous inquièter des trous de sécurité, en supposant que vous parveniez à faire fonctionner ce que vous souhaitez. Ceci alors que vous avez une solution disponible avec BOT.

Mon but est d'abord la recherche maximale de la sécurité du produit en évitant les failles de sécurité potentielles des addons.

Par ailleur je ne peux qu'abonder dans la direction de Poupou94. Alors que les régles pas défaut d'IPCOP laissent tout sortir et qu'avec BOT on bloque tout, je ne vois pas bien quel trou de sécurité cet addon risquerait d'apporter. Ce que vous en faite est une autre histoire.

Vous avez un don pour prendre les choses à l'envers. Si on regarde les risques :
1 - Ipcop de base quels risques sans contrôle di traffic sortant ?
2 - Utilisation de BOT quelles failles pour ipcop ?
Il n'est pas difficile de comprendre que la situation 1 est incomparablement plus dangeureuse que la 2.
Il me semble rationnel de traiter les risques par ordre d'importance: les plus forts en premier.
Ensuite qu'est ce qui vous fait craindre des failles apportées par BOT ?

Pas vraiment d'accord. IpCop segmente bien mon réseau de manière fiable et toutes les redirections de port hormis ce trafic NetBios échoue

Le problème c'est Netbios et les implémentations TCP de Microsoft ainsi que le protocole smb. Ce n'est pas iptables. Donc encore une fois si on doit mettre les mains dans iptables avec IPCOP c'est que le produit ne couvre pas le besoin. Ce qui est parfaitement concevable, il y a des configurations impossibles à gérer avec ipcop. Et dans ce cas on prend un autre produit.

Enfin la recherche sur le forum ipcop avec "wins netbios" (tous les termes) donne 66 réponses à des questions similaires à la votre.

[JarodOnTheNet]

- L'installation de Block Out Traffic qui va en mode graphique normalement écrire tout çà pour moi et
me rajouter des facilités de groupes d'objets, groupes de services, groupes de protocoles, etc ...

MAIS l'idée de départ est de m'en passer.

Je comprend mal l'idée de se passer de ce qui donne la solution et de s'obstiner sur ce qui ne la donne pas, ou difficilement.

Cela peut paraitre difficile, je le conçois mais j'ai mes raisons que je n'expliquerai pas ici


Libre à vous maintenant d'ajouter je ne sais combien de lignes dans /etc/rc.d/rc.firewall. Si vous ne maitrisez pas iptables, pour le coup vous pourrez vous inquièter des trous de sécurité, en supposant que vous parveniez à faire fonctionner ce que vous souhaitez. Ceci alors que vous avez une solution disponible avec BOT.

Mon but est d'abord la recherche maximale de la sécurité du produit en évitant les failles de sécurité potentielles des addons.

Par ailleur je ne peux qu'abonder dans la direction de Poupou94. Alors que les régles pas défaut d'IPCOP laissent tout sortir et qu'avec BOT on bloque tout, je ne vois pas bien quel trou de sécurité cet addon risquerait d'apporter. Ce que vous en faite est une autre histoire.

Vous avez un don pour prendre les choses à l'envers. Si on regarde les risques :
1 - Ipcop de base quels risques sans contrôle di traffic sortant ?
2 - Utilisation de BOT quelles failles pour ipcop ?
Il n'est pas difficile de comprendre que la situation 1 est incomparablement plus dangeureuse que la 2.
Il me semble rationnel de traiter les risques par ordre d'importance: les plus forts en premier.
Ensuite qu'est ce qui vous fait craindre des failles apportées par BOT ?

Je me demande ce que vous auriez répondu avant la création de BOT. Et si demain le projet tombe ? En résolvant mon problème, je pourrais encore tourner et utiliser IpCop qui est la base.

Pas vraiment d'accord. IpCop segmente bien mon réseau de manière fiable et toutes les redirections de port hormis ce trafic NetBios échoue

Le problème c'est Netbios et les implémentations TCP de Microsoft ainsi que le protocole smb. Ce n'est pas iptables. Donc encore une fois si on doit mettre les mains dans iptables avec IPCOP c'est que le produit ne couvre pas le besoin. Ce qui est parfaitement concevable, il y a des configurations impossibles à gérer avec ipcop. Et dans ce cas on prend un autre produit.

Enfin la recherche sur le forum ipcop avec "wins netbios" (tous les termes) donne 66 réponses à des questions similaires à la votre.

J'ai finalement résolu mon problème et constate que je peux sans addons, sans WINS (sachez qu'il existe une multitude de petits réseaux qui veulent se protéger et qui n'ont pas envie d'implémenter 1 WINS par segment), sans VPN et faire l'équivalent en encodant dans les pinholes très peu de lignes. Et pour sauvegarder tout cela, juste le menu de sauvegarde. On peut très vite reconstruire en cas de crash sur des firewalls de production si on prévoit du matériel identique en maintenance.

Maintenant, je vous donne raison sur votre explication, cela semble tordu et çà l'est. Il est bien évidemment plus simple d'utiliser BOT mais maintenant, mis à part les facilités de groupages il ne va pas m'apporter grand chose si ce n'est qu'il va tout bloquer sauf ce que je vais laisser passer. Concernant BOT d'ailleurs, je n'ai jamais dit que je ne l'utiliserais pas mais qu'il viendrait après dans ce labo.

Par contre, je pense qu'il va me compliquer un peu la reconstruction en cas de crash. Je pense donc à une solution de Disaster en tenant compte qu'il y aura 1 carte-mère, 1 disque dur et 2 cartes réseaux identiques en maintenance par serveur ou groupe de serveur de production. Cela peut paraitre énorme mais au prix où coûte le matériel, autant ne pas s'en priver. On substitue, on remet en ligne et ensuite, on trouve une alternative.

Merci de vos remarques même si depuis le début, elles me paraissent assez sèches. N'oubliez-pas vos début sur IpCop, même si maintenant vous l'oubliez un peu car vous en avez la maitrise. Tout le monde n'est pas encore là et on ne peut pas dès le début tout connaitre. Merci donc d'être un peu plus conciliant.

Si vous avez la gentillesse de m'aider dans une solution simple et rapide pour un disaster sur un IpCop et Bot et de me faire profiter de votre expérience, je suis preneur.

Au plaisir de vous lire

[ccnet]

Par contre, je pense qu'il va me compliquer un peu la reconstruction en cas de crash. Je pense donc à une solution de Disaster en tenant compte qu'il y aura 1 carte-mère, 1 disque dur et 2 cartes réseaux identiques en maintenance par serveur ou groupe de serveur de production. Cela peut paraitre énorme mais au prix où coûte le matériel, autant ne pas s'en priver. On substitue, on remet en ligne et ensuite, on trouve une alternative.

Cela ne me parait pas énorme du tout. Les utilisateurs (et leurs patrons) sont devenus de plus en plus exigeants sur la continuité de service et les délais de restauration en cas de problème matériel.
Pour ma part j'installe très souvent les IPCOP sur des vieux serveurs PIII (Compaq DL360: on en trouve facilement, peu couteux, 1U, 2 inteface ethernet en standard) avec une paire de disques en RAID 1 (toujours). J'ai pu expérimenté la disquette de sauvegarde et restauration avec l'agréable surprise de retrouver aussi ma config VPN (Zerina) en place. Pour des raisons stupides et (non techniques) BOT n'était pas installé. C'est parfaitement fonctionnel entre deux hardware très différents. Reste à tester avec BOT installé. Sous réserve d'avoir le même matériel en spare (c'est là que les stocks de DL360 à 100 euros pièce sont agréables) une image binaire devrait convenir aussi.

[JarodOnTheNet]

Par contre, je pense qu'il va me compliquer un peu la reconstruction en cas de crash. Je pense donc à une solution de Disaster en tenant compte qu'il y aura 1 carte-mère, 1 disque dur et 2 cartes réseaux identiques en maintenance par serveur ou groupe de serveur de production. Cela peut paraitre énorme mais au prix où coûte le matériel, autant ne pas s'en priver. On substitue, on remet en ligne et ensuite, on trouve une alternative.

Cela ne me parait pas énorme du tout. Les utilisateurs (et leurs patrons) sont devenus de plus en plus exigeants sur la continuité de service et les délais de restauration en cas de problème matériel.
Pour ma part j'installe très souvent les IPCOP sur des vieux serveurs PIII (Compaq DL360: on en trouve facilement, peu couteux, 1U, 2 inteface ethernet en standard) avec une paire de disques en RAID 1 (toujours). J'ai pu expérimenté la disquette de sauvegarde et restauration avec l'agréable surprise de retrouver aussi ma config VPN (Zerina) en place. Pour des raisons stupides et (non techniques) BOT n'était pas installé. C'est parfaitement fonctionnel entre deux hardware très différents. Reste à tester avec BOT installé. Sous réserve d'avoir le même matériel en spare (c'est là que les stocks de DL360 à 100 euros pièce sont agréables) une image binaire devrait convenir aussi.

Ok, bonnes nouvelles en perspectives. Je vais donc tester avec BOT parce que je n'ai pas encore installé Zerina. Je vais également tenter un Ghost 2k3 (soyons fou) et l'équivalent OpenSource.

Je fais remonter le résultat lorsque j'aurai fait le test, mais comme je reprends le boulot demain avec une migration de domaine en perspective avec de mutiples vlans et du routage Inter-Sites et le touti quanti, çà risque de me prendre un peu de temps.

Pour l'instant, je me pense sur Block Out Traffic ...

Merci de l'info et à bientôt

[bigsantos]

J'ai finalement résolu mon problème et constate que je peux sans addons, sans WINS ...

Salut.

Peux-tu nous donner de façon detaillée la demarche entreprise pour résoudre ce probleme.