|
Auteur: acvw (---.skynet.be)
Date: 12-11-01 21:44
Ayant l'adsl depuis peu, je désire installer un firewall mais en français. J'avais déjà Look'n'stop, mais trop de problème avec windows. Avez-vous une idée ?
|
|
Répondre à ce message
|
|
Auteur: proxy (---.ipt.aol.com)
Date: 13-11-01 06:57
Slt,
http://www.chez.com/manland/progs.htm Tu as Tiny en français...pour moi le meilleur firewall!
Proxy
|
|
Répondre à ce message
|
|
Auteur: yannick (---.abo.wanadoo.fr)
Date: 13-11-01 14:14
essaie zone alarm je sais qu'il existe un patch pour le mettre en français
|
|
Répondre à ce message
|
|
Auteur: Hubert (195.83.69.---)
Date: 13-11-01 15:47
Recherche documentation (en français) sur les firewall pour exposé
|
|
Répondre à ce message
|
|
Auteur: proxy (---.ipt.aol.com)
Date: 14-11-01 06:57
Salut tous:)
Le site de Dark cristal c pour le patch français de Zone Alarm...
Sinon pour ce qui concerne les firewalls vas sur le site de
http://websec.arcady.fr
Le firewall est-il la panacée ?
La protection du réseau à l'aide d'un firewall est-elle réellement efficace ? A cette question, la réponse de nos experts est unanime : il n'est pas de firewall infaillible, et le coupe-feu ne saurait constituer l'outil de sécurité absolu. On a affaire à une équation à "n" inconnues pouvant déboucher sur des solutions multiples et variées.
Les limites du périmètre de sécurité d'un réseau sont en général déterminées par un ou plusieurs éléments coupe-feu, dont l'administration sera impérativement centralisée. Par conséquent, établir un périmètre de sécurité consiste à désigner le ou les réseaux de machines et de ressources à protéger. La limite de ce périmètre constitue donc le lieu où toutes les connexions entrantes et sortantes seront contrôlées. L'autorisation pour que le paquet puisse traverser le firewall sera alors définie par des règles comme : - l'adresse d'origine ou de destination du paquet, - le protocole utilisé, - le port de connexion, - le sens de la connexion. Le coupe-feu, ou firewall, constitue la seule et unique passerelle de communication pour tous les hôtes situés à l'intérieur de la zone protégée. Pour que ce périmètre de sécurité réseau soit réellement efficace, il faut que toutes les communications entrantes ou sortantes établies transitent par le firewall. Cet élément joue donc un rôle primordial dans la solution, puisqu'il protège le fameux périmètre de sécurité. A cette fin, le pare-feu met en œuvre un mécanisme de filtrage dynamique des paquets. Il comporte aussi un "contrôleur" de sessions et un dispositif qui analyse l'ensemble des couches réseau. Les paquets sont donc analysés au-delà de l'en-tête IP, et ce quel que soit le protocole de transport exploité (TCP, UDP, ICMP, RPC). Chaque session est autorisée ou refusée en fonction des règles de filtrage établies. L'événement est enregistré avec un maximum de détails (ports source et destination, heure, date, numéro de règle concerné...) et conservé dans une base de données. L'attention doit porter sur la mise en place de zones démilitarisées (DMZ) ou sous-réseaux. Ces zones sont le plus souvent destinées à héberger des équipements plus ou moins sensibles ou ayant un rôle bien précis dans la topologie de sécurité déployée. Elles agissent donc comme des "compartiments" totalement ou partiellement étanches. Les différentes parties du réseau protégé utilisent des plans d'adressage déterminés selon les besoins de fonctionnement et peuvent être segmentées comme suit : le réseau "fournisseur d'accès" de raccordement à l'Internet, autrement dit l'extérieur ; la ou les zones dites démilitarisées, avec une ou plusieurs DMZ publiques, une DMZ privée ; le réseau interne. Les flux de communication devront ainsi impérativement être inspectés en détail, et ce jusqu'aux données qui entrent dans le périmètre. Cette activité est fréquemment réalisée par des éléments "périphériques" et indispensables, afin que l'inspection soit complète et qu'il n'y ait aucun doute sur la nature malveillante du paquet. Dans ce contexte, l'activité du firewall est complétée par des serveurs et des équipements utilisés pour contrôler ou alerter en cas de situation anormale. Par conséquent, un pare-feu déployé sans aucun complément peut vite rendre vulnérable un réseau, car il ne peut analyser et inspecter les paquets jusqu'au niveau des données elles-mêmes. Pour résumer, la mise en œuvre d'un firewall débutera obligatoirement par sa configuration. Dans un premier temps, ce firewall sera réglé pour ne rien laisser passer, et cela quel que soit le sens (entrée, sortie du réseau ou accès vers et depuis la DMZ.). En fonction des besoins, les règles permettant l'accès seront ajoutées au fur et à mesure, afin que ne soient établies que les connexions autorisées dans le cadre de la politique de sécurité. Autre point à considérer lors de la mise en route de la porte coupe-feu : l'adressage du périmètre de sécurité, qui devra être confidentiel. A cet effet, le mécanisme de translation des adresses sera activé et démarré sur le(s) firewall(s), et routeurs, afin de masquer complètement les adresses du réseau interne. Cette translation sera de type statique ou dynamique selon les besoins. On notera que, vis-à-vis de l'extérieur, toutes les communications IP utilisent dans ce cas- la même adresse, ou un nombre d'adresses très restreint. Cela apporte de l'efficacité en terme de debugging, mais aussi - et surtout - permet d'autoriser uniquement cette ou ces adresses IP à sortir via le routeur d'accès à l'Internet. Ainsi, dans le cas de deux sous-réseaux DMZ (une DMZ publique et une DMZ privée par exemple) et d'une interface vers le réseau interne, chacun des sous-réseaux sera obligatoirement compris dans une plage d'adresses unique. Les serveurs situés sur la DMZ publique doivent être accessibles depuis l'extérieur (Internet). Dans ce cas, ils pourront recevoir soit directement une adresse publique et routable, soit une adresse interne et non routable sur l'Internet. S'il s'agit d'une adresse interne (RFC1918) et non routable, un serveur web sur une DMZ ne sera pas directement accessible à partir de l'Internet. Pour l'atteindre, les internautes iront jusqu'au firewall qui hébergera sur son interface externe l'adresse publique du serveur cible. Sa fonction sera de traduire cette adresse vers l'adresse interne du serveur web, rendant ainsi l'accès possible. Dans ce schéma, le pare-feu tient le rôle de chef d'orchestre et peut empêcher tout accès direct vers ledit équipement. C'est le principe de la translation d'adresses.
"Rester humble devant le hacker"
A la question "Le firewall est-il efficace ?", la réponse est oui, pour peu que l'administrateur mesure la juste place de cet élément dans le dispositif de protection de son réseau. Le firewall ne saurait assurer la sécurité globale du réseau, mais il peut être très efficace dans son périmètre de gestion de la sécurité. Si l'on connaît bien les types d'attaques et de malveillances que couvre le pare-feu, si l'on maîtrise les architectures où il joue vraiment son rôle, si l'on sait mettre en place l'organisation opérationnelle (gestion quotidienne des alarmes, suivi de l'historique des attaques contre le réseau...), alors le firewall donnera la pleine mesure de son efficacité. Il faut cependant être conscient de ses limites ; le pare-feu reste un dispositif avec des failles, des limitations - en termes de flux de trafic, de nombre de sessions, etc. Pour pallier ses défaillances, on s'attachera à choisir matériel et le système d'exploitation les plus appropriés. Il faut aussi procéder très régulièrement à la mise en place de correctifs ; vu les délais de développements de ces correctifs, l'utilisation de plusieurs technologies (mise en cascade de firewalls conçus par des constructeurs ou éditeurs de logiciels différents) sera judicieuse. Le point essentiel reste que la sécurité fournie par un firewall ne suffit pas : il faut l'associer à d'autres types de protection au niveau système (checksum pour vérifier l'intégrité des données, wrapper pour limiter l'accès au processus) et au niveau applicatif (antivirus, authentification forte...). On sait que le firewall est dédié au filtrage de trafic sur réseau fixe. Sur un Wireless LAN, par exemple, il faudra donc mettre en place d'autres systèmes de protection pour filtrer le trafic vers les machines équipées de liaisons type RLAN. Autre message important : même si les règles d'ingénierie et d'administration sont rigoureusement respectées, l'administrateur sécurité doit faire montre d'humilité face aux hackers, personnages dont l'inventivité paraît sans limite. L'historique des attaques sur les réseaux illustre bien l'ingéniosité des pirates et la difficulté d'anticiper leurs actions. L'administrateur doit donc continuer en permanence sa veille technologique, garder un contact régulier avec les centres d'expertise de sécurité, vérifier et analyser régulièrement les traces enregistrées par le firewall. L'humilité, devant tous ces dangers, implique aussi que l'administrateur accepte l'introduction d'une tierce partie comme arbitre de sécurité. Le lancement régulier d'audits de sécurité techniques et organisationnels permettra de bénéficier d'un regard extérieur critique sur la pertinence des procédures en place, le social engineering, le respect strict de la sécurité physique du firewall... et de recueillir des recommandations constructives.
"Eviter les pièges d'une installation trop aisée"
L'installation d'un firewall couvre en général 90 % des risques liés à l'interconnexion avec un réseau non inclus dans le même espace de confiance... Bien sûr, les pirates se ruent sur les 10 % restants. L'entreprise qui veut se protéger contre de nouveaux assauts doit donc continuer à maintenir son architecture de sécurité afin qu'elle reste solide. Pour cela, il convient d'abord de peaufiner la configuration de certains firewalls installés à la légère. Des erreurs de configuration qui, naguère, n'étaient pas forcément visées par les pirates sont aujourd'hui des failles sur lesquelles ils se focalisent. La simplicité de configuration des firewalls via une interface graphique conviviale n'est qu'un leurre, et configurer un pare-feu reste une affaire de spécialiste sécurité. Une fois cette étape correctement réalisée vient le plus difficile : s'occuper des flux autorisés par le firewall (accès au web et à la messagerie, flux applicatifs...). Il faut rechercher, flux par flux, les faiblesses du pare-feu et mettre en œuvre la configuration et les produits tiers qui aideront à sécuriser chacun d'entre eux. Citons quelques exemples. - La résolution DNS est indispensable pour permettre la consultation du web (par un utilisateur ou un serveur comme celui de la messagerie). Le firewall sera donc configuré pour autoriser le transit des flux DNS. Cette configuration, très fréquente, a le don d'irriter les spécialistes sécurité. La parade, dans ce cas, consiste à scinder le DNS en un DNS externe et un DNS interne. Le DNS interne retransmettra les demandes de résolution de noms de machines externes au DNS externe placé sur la DMZ. C'est une configuration connue depuis très longtemps mais pas assez souvent mise en œuvre. Par ailleurs, un vieux cheval de Troie comme Back Orifice peut tout à fait être configuré pour utiliser le port DNS. - Sur de nombreux firewalls, on trouve une règle destinée à permettre au relais de messagerie (en DMZ) d'envoyer un mail sur Internet. Les serveurs de messagerie sur Internet pouvant être hébergés sur n'importe quelle adresse IP, la règle est rédigée de la façon suivante : Source : relais-de-messagerie, Destination : Any, Port : SMTP. Cette règle autorise le serveur de messagerie à se connecter sur le port SMTP de toute machine du réseau interne, mais est-ce vraiment ce qui est recherché ? "Any" est beaucoup trop permissif dans ce cas. Il faut partir du fait que tout "service" (web, messagerie...) accessible depuis l'extérieur est potentiellement piratable. On s'assurera donc tout d'abord que ce service est également bien paramétré et configuré de façon sécurisée. Il convient ensuite de s'interroger sur les conséquences éventuelles si, malgré tout, il était piraté (vulnérabilité du logiciel serveur, par exemple. L'architecture système et réseau doit prévoir ce cas de figure et y parer. Par exemple, le serveur concerné ne doit posséder aucun droit sur une machine du système d'information interne. Sinon, on s'exposerait à une "attaque par rebond"
@+
Proxy
|
|
Répondre à ce message
|
|
