Articles précédents : Articles
- [78] Comparaison entre les noyaux 2.4.25 et 2.6.4
- [6] Le gouvernement brésilien persiste et signe pour Zope et Plone
- [44] Tentative de support des Webcams USB basées sur les puces ZC030X
- [43] Sortie de Wesnoth 0.7
- [7] Divergence Numérique n°6, jeudi 25 mars de 19h00 à 20h00
- [34] Wikipédia Francophone fête ses 3 ans
- [64] Conférences et manifestation contre la Tyrannie des brevets dans l'Union Européenne, le 14 Avril 2004 à Bruxelles
- [89] Pirates Mag' en mauvaise posture.
- [38] L'OpenSource par Trolltech
- [138] Salon du jeu vidéo sur plateforme libre
Liens connexes
- Firewall Failover with pfsync and CARP (1218 hits)
- Nouveautés OpenBSD 3.5 (725 hits)
- UCARP (600 hits)
- Dernier titre musical d'openBSD (653 hits)
Dépêche modérée par
Articles : Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Foxy (page perso, ). Modéré le 30 mars 2004.
Le développeur OpenBSD (Ryan McBride) présente dans l'article suivant cette fonctionnalité basée sur pfsync (réplication de la tables des connexions actives entre firewalls OpenBSD) et CARP (Common Address Redundancy Protocol, équivalent libre du protocole Cisco VRRP).
Le protocole CARP autorise plusieurs machines à partager la même adresse IP et la même adresse MAC. Il est alors possible de créer un cluster de firewalls redondants mais aussi de gérer un cluster de serveurs Web redondants sans oublier un équilibrage de charge :-)
NdM : je vous invite à écouter le dernier titre musical d'OpenBSD, qui est une comédie musicale abordant ce sujet.
![[en]](../../../images/en.png)
Firewall Failover with pfsync and CARP (1218 hits)-
Nouveautés OpenBSD 3.5 (725 hits)
-
UCARP (600 hits)
-
Dernier titre musical d'openBSD (653 hits)
> Lire la suite (44 commentaires, moyenne: 2,2). [dépêche : 152 caractères]
Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Quand on voit les fonctionnalités disponibles avec les pare-feux libres (comme pf ou iptables), quel est encore l'intérêt d'aller installer des pare-feux propriétaires comme 6co Pix ou Checkpoint FW1 ?
Y a-t-il des trucs que les firewalls proprio savent faire et qui sont impossible à réaliser avec des outils libres ?
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par mdlh () le 30/03/2004 à 13:16. (lien). Évalué à 3.Pour 6co Pic je sais pas. Pour checkpoint, je crois qu'encore une fois c'est surtout l'ergonomie qui plait a certains.
J'ai vu pas mal de chose sympa que l'on pouvait faire avec depuis une seule interface. Le site que je visitais avait plusieurs firewall (1 entre Internet et la DMZ, 1 entre Internet et le reseau interne, et 1 autre entre la DMZ et le reseau interne).
Bref, checkpoint leur permettait de gerer a la fois les 3 firewall sans reellement se soucier de savoir lequel ils modifiaient a chaque fois. Apparament, tu formalises d'abord plus ou moins la topologie de ton reseau et apres, tu dis juste "Je veux que le poste puisse acceder au port de(s) Ip(s) .
Apres l'appli cliente se charge d'envoyer les bonnes regles aux firewalls idoines.
Mais bon, ca c'est ce que les gars m'avaient dit, apres je suis pas aller verifier de plus pret.
Par contre, je sais pas si une telle appli existe dans le libre. J'adorerais une reponse disant que je me trompe avec une jolie URL.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par logout () le 30/03/2004 à 13:43. (lien). Évalué à 3.Par contre, je sais pas si une telle appli existe dans le libre. J'adorerais une reponse disant que je me trompe avec une jolie URL
Il y a Firewall Builder qui correspond un peu a ce qui peut ce faire avec l'interface de checkpoint
http://www.fwbuilder.org/(...)
Par contre j'sais pas si l'url est jolie...
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par PLuG () le 30/03/2004 à 13:51. (lien). Évalué à 7.checkpoint c'est surtout:
- des licenses liées aux adresses IP du parefeu (très chiant pour remanier le reseau...),
- des licenses chères et conditionnées par le nombre d'adresses IP "internes",
- des couts de support astronomiques,
- une interface qui ne permet pas de faire TOUT ce que l'on peut faire avec la grammaire d'iptables, (interface qui tourne sous windows),
- des logs dans un format propriétaire (fini les grep pour chercher des trucs),
- un traitement pour le moins bizarre des ICMP (passe, passe pas ... pas d'explication).
- une configuration fouillie (définir un VPN revient a mettre des morceaux d'information sur l'objet "cluster", la gateway d'en face, chaque règle de filtrage ... y'en a partout. Certaines infos sont valables pour tous les VPN, du coup une modif impacte tous les tunnels a la fois. C'est un vrai merdier comparé a Freeswan.
Checkpoint ne vend, a mon avis, QUE parce qu'il profite de sa position de leadeur sur le marché, position acquise quand le marché était vierge de concurence a la hauteur. Mais cette position est largement USURPEE de nos jours !!! les décideurs mettent du checkpoint "parce que personne ne pourra le leur reprocher", comme ils le font quand ils choisissent les plus gros, pas du tout sur des critères techniques.
Le plus c'est l'interface d'admin ... comme ca n'importe quel couillon peut modifier les règles en cliquant. ça me fait marrer moi, on voit le résultat avec les "pseudo" administrateur windows ... confier la sécurité de sites a ce genre de personnage est pour le moins fantaisiste.
iptables, ou meme cisco pix sont bien plus sérieux:
avec un pix, un fichier texte défini TOUT le setup de la machine. Vous avez reçu un nouveau pix pour mettre a la place de l'ancien ? connection null-modem avec minicom, copier/coller de ce fichier texte ==> hop, 5 minutes après le pix est en place. ça c'est pro !!
Et pour gérer un parc entier de pix ?? il existe des produits chez cisco, mais n'importe quel admin pas trop con pourra se faire un script ki-va-bien qui se connecte en ssh et administre de façon centralisée les pare-feux.
cependant quand on en est la, pourquoi ne pas prendre pf ou iptables ??
avec un bsd/linux, on aura loisir de débugger correctement les problèmes (tcpdump, ...) de monter des clusters (vrrpd, heartbeat ) et de maitriser vraiment comment se passent les choses.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Mathieu Millet (page perso, ) le 30/03/2004 à 14:05. (lien). Évalué à 4.Je suis en partie d'accord avec toi.
checkpoint c'est surtout:
- une configuration fouillie (définir un VPN revient a mettre des morceaux d'information sur l'objet "cluster", la gateway d'en face, chaque règle de filtrage
Pour information, pour les VPN type client-passerelle, soit tu ne paies pas en plus, et tu as du VPN, non standard qui ne fonctionne qu'a moitie, soit tu paies encore plus et tu as du VPN presque standard qui fonctionne presque totalement. (ben oui, ca aurait etre trop beau que ca marche farpaitement).
C'est un vrai merdier comparé a Freeswan.
Sauf que Freeswan est maintenant un projet abandonne. Il faut se reporter a openswan ou la pile Kame de BSD.
et avec Freeswan, il est difficilement possible d'utiliser un mecanisme d'authentification forte (type one-time password ou calculette) par utilisateur. (Les certificats c'est bien gentil, mais la gestion d'une PKI, c'est un poil lourd).
il existe des produits chez cisco,
Tu connais le prix et la complexite de mises en oeuvre de ces produits ?? Regarde, tu vas etre surpris.
cependant quand on en est la, pourquoi ne pas prendre pf ou iptables ??
avec un bsd/linux, on aura loisir de débugger correctement les problèmes (tcpdump, ...) de monter des clusters (vrrpd, heartbeat ) et de maitriser vraiment comment se passent les choses.
Ah, la y'a pas photo. Seulement, dans l'article, il est marque que VRRP est soumis au brevet de Cisco (le brevet HSRP). Donc, s/VRRP/CARP.--
htam
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par floo () le 30/03/2004 à 15:44. (lien). Évalué à 1.Certes Checkpoint est plus cher
Certes l'interface et la config sont un peu bizarre par moment (par contre ICMP je vois pas où ??)
En revanche ce n'est pas parce que l'interface est graphique que ce sont des couillons qui l'utilisent. Tu peux toujours aller modifier les fichiers textes de config (qui existent !!) si tu veux .... Mais quand tu as autre chose à faire que ça pendant 90% de ton temps, l'interface graphique pour administrer une dizaine de firewall et quelques VPN, plus des remotes access, c'est quand même assez agréable
Enfin il a existé un moment un package BASH+PERL+MRTG sur les IPSO de Nokia/Checkpoint. Tcpdump était bien entendu fourni. Et certains produits checkpoint sont maintenant basé sur RedHat (SecurePlatform)
Je ne connais pas les interfaces graphiques de iptables, mais pour avoir l'habitude de celle de checkpoint, je la trouve plutôt pratique-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par PLuG () le 31/03/2004 à 07:21. (lien). Évalué à 2.par contre ICMP je vois pas où ??
ben par exemple, tu essaie de faire passer des icmp dans un vpn, un coup ça marche un coup ça ne marche pas ...
autre exemple: tu essaie de nater des icmp ... a ben non, l'interface ne "veut" pas, on ne peux nater que du tcp ou de l'udp mais pas de l'icmp ???? (ou alors il faut TOUT nater). Cet exemple de nat me semble démontrer que l'implémentation de ce bordel est pour le moins bizarre: le NAT ca se fait au niveau IP, puis de temps en temps avec des astuces dans les couches supérieures, mais rien ne devrait empecher de le faire au niveau IP (donc en dessous de icmp ...).
ce n'est pas parce que l'interface est graphique que ce sont des couillons qui l'utilisent
je ne pense pas avoir écrit cela. Quand on me dit "l'interface graphique permet a tout le monde de comprendre les règles", cela ne me rassure pas. Je ne veux pas que "tout le monde" comprenne les règles, mais seulement les experts ... les autres n'ont rien a foutre devant la console.
Sinon, il est possible (et simple) de gerer plein de firewall en parallele avec des scripts et du ssh, pas besoin de console sous windows lennnnte a mourrir (lecture du log ... ouarf, inutilisable sauf a acheter un produit checkpoint dédié supplémentaire !!!)
Je connais pas mal les nokia, effectivement il y a tcpdump mais aucune solution pour sniffer dans les tunnels par exemple (alors que "tcpdump -n -i ipsec0" le fait bien). Quand a faire tourner checkpoint sur une redhat, la cela me depasse carément vu que iptables est déja la.
honnetement, j'ai pas mal l'habitude de checkpoint, des pix (pas si cher que ca pour les pix 515 et tellement beau comme méthode de clustering), et de iptables.
checkpoint est "beau" au départ, et puis viens le problème des upgrades, des sauvegardes, de la restauration, de la duplication de configuration.... rien ne marche comme prévu (ou logique). Par exemple, il te manque un node a ton cluster checkpoint (il est physiquement en panne), impossible de changer les règles sur le "cluster", message d'erreur a cause du node manquant et hop abandon....
les pix ont leur soucis également (nat pas simple, voir impossible dans certains cas ou la "grammaire" du pix ne permet pas d'exprimer ce que l'on veut faire), mais au moins tout ce qui est prévu fonctionne normalement !!
un bémol cependant, quand je parles de checkpoint, c'est la v4.x la migration vers NG était tellement chère qu'on s'est abstenu et avons jeté l'ensemble des nokia+checkpoint lors de la dernière faille de sécurité. OUF !!-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Olivier () le 31/03/2004 à 14:49. (lien). Évalué à 3.Hello,
Je n'ai pas envie de me faire grand défenseur de Checkpoint mais je pense que tu parles de Checkpoint en te référant à la version 4.1 au maximum ... depuis les versions successives de NG sont là (depuis près de 4 ans maintenant) et le saut technologique est majeur.
J'ai la chance de travailler dans ce domaine depuis quelques années ... j'ai commencé sur les version 3.0b, puis 4 et maintenant on utilise du NG et aussi AI.
checkpoint c'est ... un acteur historique sur le marché (oui ils en profitent et pour moi c'est un peu le Ms de la sécurité !) mais néanmoins ils améliorent sans cesse leurs produits.
C'est aussi un GUI qui tient la route ... suffisemment accessible pour beaucoup mais qui permet de faire énormément de choses sans devoir mettre la main dans les fichiers de config. J'ai de la chance de "maîtriser" les deux mais je pense ne pas faire partie de la majorité !
Pour les VPNs ... j'aime pas leur manière de faire ...
Maintenant il n'y a pas que checkpoint ... on utilise beaucoup Netscreen et ça vaut vraiment la peine de regarder ce qu'ils font ... oui c'est propriétaire mais je ne suis pas sectaire ;o)
Quand à Cisco ... restons sérieux ... un pix n'est pas un vrai firewall !!! Ce sont des access list avec du NAT ... rien d'autre !
IPtables donne de superbes résultats quand on sait l'utiliser ... mais il est dangereux pour une société de se fier au savoir faire d'un guru ;) Oui ça peut paraître simpliste comme argumentation mais c'est un fait que j'ai vérifié dans les différentes entreprises où j'ai été.
Mes 2 cents ;)-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par PLuG () le 01/04/2004 à 11:41. (lien). Évalué à 3.mais je pense que tu parles de Checkpoint en te référant à la version 4.1
ben y'a pas besoin de "penser", je l'ai écrit dans mon post.
NG nous avons réussi a l'éviter. Mais sinon:
- TOUTES les personnes qui l'utilisent pour faire du VPN me disent que c'est encore pire qu'en 4.1.
- Les aures m'ont clairement dit "not worth the money"...
En gros, sur la 20aine de personnes différentes réparties dans les entreprises que je cotoie (en France, Allemagne, Angleterre, USA, ...) , AUCUNE ne m'a dit du bien de NG. (exemples de contournements a mettre en place pour que cela marche, lots d"astuces" pour que le biniou veuille bien faire ce qu'on lui demande, ... jusqu'aux migrations pas du tout simples de 4.1 a NG).
De la a renforcer mon opinion sur checkpoint et éviter de payer pour NG ...
Quand à Cisco ... restons sérieux ... un pix n'est pas un vrai firewall !!! Ce sont des access list avec du NAT ... rien d'autre !
un pix c'est quand meme un firewall statefull, un mode de clustering exemplaire de simplicité, des acl oui, mais c'est le lot de tout firewall les acls. Ton checkpoint fait la meme chose !! Tu crois vraiment qu'un checkpoint fait plus ??? lol.
maintenant si pour toi un firewall se doit de comprendre aussi les proxy applicatifs, ben effectivement ça ne le fait pas. mais c'est un + a mes yeux, les proxy applicatifs n'ont rien a faire dans un équipement réseau.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vincent Haverlant (page perso, ) le 02/04/2004 à 05:53. (lien). Évalué à 2.- TOUTES les personnes qui l'utilisent pour faire du VPN me disent que c'est encore pire qu'en 4.1.
Je ne suis pas d'accord et j'aimerais bien en connaitre leurs arguments.
En ce qui concerne not worth the money, ça peut se discuter. En ce qui me concerne le seul reproche que je ferai à un FW checkpoint par rapport à PF ou Netfilter c'est de ne pas pouvoir choisir une interface où appliquer une règle. C'est le seul endroit où je ne peux pas faire exactement la même chose.
En revanche, pour ce qui concerne l'industrialisation, je continue de pense que checkpoint a quelques longueurs d'avance malgré des projets comme FWbuilder. La console d'admin en NG fonctionne très bien, permet de gérer un grand nombre de FW et de configurations, permet de définir des users, des droits et des permissions avec une assez bonne granularité en ce qui concerne les actions possibles via la GUI.
Et puis vous avez tendance à oublier quelques petites choses qui sont assez faciles à faire avec un CP alors qu'avec autre chose.... Authentification des flux (d'accord, c'est faisable avec pfauth et pix) mais avec plusieurs sources d'authentification (LDAP, radius, authentificaiton interne, authentification OS), CVP (Content Verification Protocl je crois) qui permet de s'interfacer avec des anti virus et autres cochoneries.
Il faut aussi noter que les dernieres versions incluent ce qu'ils appellent SmartDefense qui rassemble quelques fonctions d'inspection au niveau 7.
Pour ce qui concerne les reproches de clickouillage que j'ai pu lire. Il me semble que c'est quand même le meilleur outil qui soit pour créer et maintenir une configuration homogène sur un gros parc de FW.
Enfin pour quelqu'un qui s'investit beaucoup il y a un certain nombre d'outils en ligne de commande qui facilitent énormément la vie (fw monitor, fw tab, dbedit...)
J'écris tout ça même si d'un point de vue personnel, en terme de filtre de paquets je préfère Netfilter qui est à mon goùt le plus efficace. Mais pour reproduire avec Netfilter + outils linux toutes les fonctions d'un Checkpoint nécessaires à des gros environnement de production, il faut se lever de bonne heure.
Maintenant rien n'empeche de mettre une couche de Netfilter ou PF puis une couche de Checkpoint....
-
-
-
-
-
[+] [^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Zenitram (page perso, ) le 30/03/2004 à 22:20. (lien). Évalué à -1.90% de ce que tu dis vaut la lecture, mais ca :
Le plus c'est l'interface d'admin ... comme ca n'importe quel couillon peut modifier les règles en cliquant. ça me fait marrer moi, on voit le résultat avec les "pseudo" administrateur windows ... confier la sécurité de sites a ce genre de personnage est pour le moins fantaisiste.
Toujours aussi marrant les intégristes : pour que ce soit puissant, il faut que ce soit horrible à utiliser, et que seul l'expert puisse dire "moi je sais faire".
Pour eux, interface texte = le mieux, GUI = pour les couillons.
hum, heuresement les linuxiens changent d'avis, mais lentement...-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Bernard Massot () le 30/03/2004 à 22:54. (lien). Évalué à 6.Je crois que tu n'as pas compris ce qu'il a dit. Il a dit que donner l'impression à un incompétent qu'il est à la hauteur dans un contexte sensible est dangereux, pas que les gens compétents voulaient absolument des interfaces imbitables pour se donner l'air puissant.
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par PLuG () le 31/03/2004 à 07:22. (lien). Évalué à 3.merci !
c'est exactement ce que je voulais dire, mais apparemment je m'y suis mal pris puisque 2 personnes m'ont répondu offusquées ...-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Cali_Mero () le 31/03/2004 à 20:06. (lien). Évalué à 1.Probablement des gens qui se croient tout-puissants mais qui se sentent tout perdus sans cliquodrome, c'est bien le seul type de personne qui peut s'offusquer de tes propos (très sensés, soit dit en passant).
et hop, +--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
-
-
-
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Mathieu Millet (page perso, ) le 30/03/2004 à 13:54. (lien). Évalué à 1.Sauf que ca va encore plus loin,...
Car via cette interface unique, tu peux gerer :
- ta topologie réseau (y compris les regles sur tes firewall),
- les terminaisons VPN (client et passerelle),
- Les procedes d'authentification (RADIUS, LDAP, Certificats...)
...
Certes, Firewallbuilder permet de faire le premier point (pour Linux/iptables, xBSD/pf/ipf, Cisco Pix ...) mais pas les autres.--
htam
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Mr F (page perso, ) le 30/03/2004 à 13:59. (lien). Évalué à 2.L'interface de Checkpoint FW1 est effectivement excellente, tu gére ton firewall à l'aide d'icônes qui sont un ensemble de rêgles, groupe de serveurs, utilisateurs ou autre. C'est vraiment très intuitif, très rapide à prendre en main et très efficace. Firewall Builder a l'air assez proche concernant le concepte.
Pour le reste, je suis assez d'accord avec le commentaire de PLuG.
Concernant le Cisco Pix, c'est une architecture propriétaire complête, ce qui permet, en théorie, d'obtenir de meilleurs performance. Le système d'exploitation est minimum et ne sert vraiment qu'a faire tourner le minimum necessaire pour le Firewall. En général, les coûts sont élevé par rapport à ce que l'on trouve sous le capôt (une bête carte mère et un processeur même pas de dernière génération), mais la recette miracle concerne normalement l'OS.
La vrai force des solutions propriétaires concerne de toute façon le support technique, toutes les sociétés n'ayant pas de personnel maitrisant les logiciels libres à la perfection...-
[+] [^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Jiel (page perso, ) le 30/03/2004 à 21:55. (lien). Évalué à -1.C'est triste ton point de vue sur la perfection.
-
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Misc (page perso, ) le 30/03/2004 à 13:56. (lien). Évalué à 2.On m'a parlé de fonctionnalités d'inspection du trafaic ( vérifiez que le port 25 c'est bien du smtp, pas du ssh pour (faire de l'irc|travaillez sur du libr^Wlogiciel communiste|échangez du porno via scp) ).
Je sais pas si ça existe en libre, je pense que c'est faisable, mais en magouillant-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Mathieu Millet (page perso, ) le 30/03/2004 à 14:14. (lien). Évalué à 5.En general, "l'inspection de trafic" consiste a verifier la coherence du protocole TCP ou UDP (et non pas le protocole applicatif au-dessus).
Genre, quand un paquet arrive a destination du paquet 25 et pretendant qu'il appartient a une connexion deja etablie, il verifie que la connexion est bien etablie. Si elle ne l'est pas, alors le paquet est considere comme frauduleux (DROP, REJECT, DISCARD, comme vous voulez).
Tres peu de coupe-feu, remonte au-dessus de TCP ou d'UDP ou alors via des relais applicatifs (relais de messagerie SMTP, proxy et reverse proxy HTTP) : Par exemple, redirection transparente de tout trafic sortant a destination du port 80, vers le proxy a cote du firewall.
Par ailleurs, une bonne pratique consiste a ne pas autoriser les postes de travail de tout usager a sortir en direct sur le grand 'ternet. Seuls des machines précises (placées si possible en zone de sécurité) ont le droit d'envoyer (et/ou de recevoir) du trafic vers Internet sur des ports/protocoles particuliers.--
htam-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vanhu () le 30/03/2004 à 14:35. (lien). Évalué à 2.Tres peu de coupe-feu, remonte au-dessus de TCP ou d'UDP ou alors via des relais applicatifs (relais de messagerie SMTP, proxy et reverse proxy HTTP)
Eh non, le "bete par feu Stateful", c'est dépassé, n'importe quel technico commercial qui bosse dans la sécurité le confirmera !!
Maintenant, les firewalls "de grands" sont capables de vérifier la cohérence jusqu'a la couche 7 (en totu cas pour les protocoles qu'ils connaissent), et donc par exemple de jeter du traffic SSH qui essaierait de passer via un port http (parceque bon, le http, on l'accepte, souvent).
Alors apres, effectivement, la plupart des produits font ca via des proxies, et pour peu que ca soit une appliance basée sur un ASIC "pas tout a fait de la derniere version qui sort des la semaine prochaine", les performances ont un peu tendance a s'effondrer lamentablement....
Mais il y a quelques produits qui font ca "proprement", rapidement, et qui ont en plus (au moins pour certains) le bon gout d'etre développés en France et d'etre basés sur des OS libres.....
Par ailleurs, une bonne pratique consiste a ne pas autoriser les postes de travail de tout usager a sortir en direct sur le grand 'ternet. Seuls des machines précises (placées si possible en zone de sécurité) ont le droit d'envoyer (et/ou de recevoir) du trafic vers Internet sur des ports/protocoles particuliers.
Ouais, alors en théorie, effectivement, c'est bien (mais ca ne résoud pas tout pour autant), mais en pratique, a part certains endroits sensibles administres par des paranos (ministeres ? armee ? societes de gestions de PKIs ou d'autres données sensibles du meme genre ? mon réseau local ? :-), j'aimerais bien voir ou on arrive a imposer ce genre de "bonnes pratiques".-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Blackknight (Jabber id, page perso, ) le 30/03/2004 à 14:51. (lien). Évalué à 2.Mais il y a quelques produits qui font ca "proprement", rapidement, et qui ont en plus (au moins pour certains) le bon gout d'etre développés en France et d'etre basés sur des OS libres.....
Netasq ??? Sur FreeBSD et IpFilter ?-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vanhu () le 30/03/2004 à 17:02. (lien). Évalué à 1.C'est pas moi qui ai cité la société en premier ! :-)
FreeBSD, oui (enfin, une "base" FreeBSD).
IPFilter non, plus depuis quelques années, le filtrage/IPS/etc est maintenant fait 100% "maison".-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Jihem () le 30/03/2004 à 20:02. (lien). Évalué à 4.Et les sources sont dispos? En l'absence de sources ou d'une plus value évidente, je ne vois pas:
-pourquoi faire plus confiance à Netasq qu'à Cisco, Symantec ou Checkpoint (exemples pris pas complètement au hasard)?
-pourquoi choisir une solution proprio plutôt qu'une autre?
Notes que je n'ai rien contre le proprio mais tant qu'à faire, je ferai plus facilement confiance à des solutions éprouvées et que la base soit du *BSD, du Linux ou du 100% proprio ne change pas grand'chose finalement (les appliances de Symantec ont une base Linux d'ailleurs).
PS: je ne travaille ni pour, ni contre les différentes marques citées.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Cédric Chevalier (page perso, ) le 30/03/2004 à 22:49. (lien). Évalué à 1.L'avantage du libre c'est que tu peux t'amuser à l'éprouver à la maison (un firewall proprio c'est quand même un peu cher pour un particulier :)) et que l'on trouve plus facilement de la doc "publique". J'entends par "publique" une documentation pas rédigée par l'entreprise (ou les développeurs), ce qui permet de connaitre un autre point de vue sur le système.
Enfin, ça n'a rien à voir, mais les solutions proprio dans la sécurité faut voir ce que ça donne déjà chez les particuliers avec BlackIce (qui est aussi, tant que j'y suis, une illustration qu'il vaut mieux ne pas mélanger un firewall avec un proxy ou un ids).
PS : plus d'infos sur les aventures de blackice sur http://www.ixus.net/modules.php?name=News&sid=630(...)
et http://securityresponse.symantec.com/avcenter/venc/data/w32.witty.w(...) (l'algo du virus est assez sympa ;))
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vanhu () le 31/03/2004 à 08:53. (lien). Évalué à 2.Et les sources sont dispos?
Euh..... Non, en tout cas, pas pour le moteur de filtrage (apres, ca n'empeche pas de contribuer a des projets externes utilisés).
-pourquoi choisir une solution proprio plutôt qu'une autre?
Bah ca, c'est a chacun de voir en fonction de ses critères:
- Efficacité (en termes de sécurité)
- Performances
- Prix
- Ergonomie de l'interface (souvent, la simplicité d'utilisation est un critère important quand on prend une "appliance")
- Produits proposés (matos, perfs, nombre d'interfaces, etc...)
- Fonctionnalités proposées (maintenant, une appliance doit aussi pouvoir faire du VPN, du DHCP, du LDAP, de l'antivirus, etc... et doit IMPERATIVEMENT pouvoir activer la cafetière quand elle détecte un problème qui va occuper l'adminsys toute la nuit....)
- Notoriété (souvent prisé par les "décideurs" qui veulent avant tout etre surs de ne pas pouvoir se faire reprocher leur "choix".....)
- Efficacité du support du constructeur
- etc......
Maintenant, faut etre lucide, des clients qui ont réellement les compétences techniques pour vérifier l'efficacité de plein de firewalls, et de choisir celui qui fait le mieux son boulot de protection plutot que celui qui a la plus belle plaquette, ca court pas les rues.....
PS: je ne peux pas vraiment affirmer la meme indépendance vis a vis des différentes marques citées :-)
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Blackknight (Jabber id, page perso, ) le 31/03/2004 à 06:58. (lien). Évalué à 2.le filtrage/IPS/etc est maintenant fait 100% "maison".
Ce qui explique pourquoi la société recherchait (ou recherche ??? ce qui pourrait m'intéresser) des développeurs BSD.
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par gebura () le 31/03/2004 à 19:03. (lien). Évalué à 2.A priori ca marche aussi sur linux je suis tombé sur ce lien il y a quelque temps
http://l7-filter.sourceforge.net/index.php.fr(...) propose un patch pour fournir des services equivalents pour netfilter et iproute2 (tc).
j ai pas testé (pas l utilité) mais ce permettra au plus septiques de faire leurs bench!
la liste des protocoles supporté est ici: http://l7-filter.sourceforge.net/protocols.php.fr(...)
a noter la presence sur le site d un lien vers un autre projet ( http://rnvs.informatik.uni-leipzig.de/ipp2p/downloads.html(...) ) qui se charge de verifier si le trafic est ou non du p2p-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Mr F (page perso, ) le 31/03/2004 à 22:17. (lien). Évalué à 0.Je suis curieux de connaitre la consommation cpu du système...
-
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par jojo2002 () le 30/03/2004 à 15:19. (lien). Évalué à 5.Le gros problème c'est que faire du filtrage de paquet (base d'un FW et de netfilter), c'est pas la même chose que de "l'inspection de contenu" (on délègue çà au proxy).
En fait, je pense qu'on peut dire que le filtrage de paquet (niveau 3), c'est mature et y a plus grand chose à inventer (traitement des canaux cachés par ex.). Donc les éditeurs sont bien emmerdés, et ils te refourguent du proxy ou du pseudo IDS qui n'a rien à foutre sur un filtre de paquet :
- çà oblige à avoir de la puissance de calcul donc à faire acheter de la machine sur-dimensionnée
- les proxys et autres IDS intégrés offrent un service mais sont loin des perfs, fonctionnalités d'un produit dédié (mod_proxy, squid, relais smtp, etc...)
- la plupart des failles graves des Checkpoints (je parle pas des DOS) concerne toujours les proxies du pare-feu...
Par contre, il y a des trucs sur lesquels ils sont encore en avance (je parle en terme d'intégration car ces fonctions existent dans le libre mais ajoutées les unes aux autres, çà devient complexe à configurer) :
- intégration VPN
- Haute disponibilité (jusqu'à maintenant...)-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par rouby () le 30/03/2004 à 20:27. (lien). Évalué à 3.Tout à fait d'accord.
D'un point de vu sec, il est préférable de séparer autant que possibles les fonctions différentes.
Un filtre de paquets sur le pare-feu, un analyseur de proto sur un proxy, et aussi un IDS sur un IDS...
De même, mélanger des fonctions comme l'IDS et le pare-feu sur un IPS (cad la même machine) est trés discutable.
C'est la nouvelle mode marketing des "technico"-commerciaux.
Perso, je préfère une bonne chaine d'alerte et une rétro-action typiquement humaine.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vincent Haverlant (page perso, ) le 02/04/2004 à 06:20. (lien). Évalué à 2.Eh bien moi je pense l'inverse. Un analyseur de niveau 7 n'a pas besoin d'être un proxy. Il te suffit de vérifier que le contenu de la connection respecte le protocole en question sans pour autant avoir la "lourdeur" d'un proxy. C'est la forces des solutions basées sur des ASICs...
Pour avoir testé les deux types, ya pas photo.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vanhu () le 02/04/2004 à 07:18. (lien). Évalué à 2.C'est la forces des solutions basées sur des ASICs...
Mouais.....
C'est pour ca que des "gros" du marché basés sur des ASICs ont des performances qui s'écroulent dès qu'on active leurs options d'IPS ? :-)
Plus sérieusement, les ASICs, ca peut etre bien dans certains cas, mais faudrait que les équipes marketing se calment un peu a ce sujet, ca a au moins autant d'inconvénients que d'avantages (surtout pour ceux qui ont une ancienne version du hard, t'as beau faire toutes les updates du firmware que tu veux, t'as quand meme un ASIC qui sait pas faire, donc des performances pourraves....).....
Enfin, je dis ca, je dois pas etre tout a fait impartial non plus, mais bon, :-)-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vincent Haverlant (page perso, ) le 02/04/2004 à 09:26. (lien). Évalué à 2.En fait, pour ce que je connais (et je suis loin de tout connaitre) les solutions a base de proxys, purement logicielles que j'ai pu utiliser étaient pires. Que ce soit du libre ou du propriétaires.
Checkpoint fait de l'intermédiaire avec son moteur inspect qui regarde le contenu des paquets sans pour autant faire office de mandataire (et encore ça dépend des cas).
Bref... ya encore du boulot, mais clairement se contenter de filtre de paquet au niveau 4 ne me parait pas suffisant.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Vanhu () le 02/04/2004 à 13:14. (lien). Évalué à 2.Il y a en fait 2 problèmes (enfin, je shématise un peu....):
D'abord, la facon "logique" de faire, a savoir passer par des proxies (ce que font la plupart des solutions, ca permet parfois de reprendre des proxies existants, donc on y gagne en dev, mais c'est lent....) ou faire de l'inspection "a la volée" (souvent en inspectant les paquets sans vraiment les "décapsuler", coté perfs, c'est nettement meilleur, mais c'est plus lourd a développer...).
Ensuite vient la grande problématique des ASICs. Les commerciaux des solutions basées sur des ASICs diront qu'un ASIC, c'est top, ca va super vite (et faut reconnaitre que c'est vrai), ils oublient juste de préciser qu'un ASIC va super vite, mais uniquement pour faire ce pourquoi il a été prévu, et que comme c'est un composant matériel cablé, pas question de le mettre à jour quand la technologie évolue.
Et actuellement, (a peu pres ?) toutes les boites qui font des solutions basées sur ASIC mettent en avant leurs perfs "filtrage pur", et recommandent meme de désactiver l'IPS sur des "coeurs de réseaux", parceque les perfs s'effondrent quand on l'active. Peut etre qu'ils "résoudront" le problème avec une future version de leur ASIC qui inclue une partie des routines d'IPS....
Maintenant, les solutions basées sur du processeur "générique" mais avec une techno a base de proxies ont le meme genre de problèmes.....
Et pour l'instant, les seuls qui tirent leur épingle du jeu dans ce domaine, c'est ceux qui sont sur un processeur "générique" ET qui ont une implémentation "kernel" de l'IPS (en clair, c'est de l'inspection, pas du proxy). Et y'en a pas beaucoup....
-
-
-
-
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par PLuG () le 31/03/2004 à 07:31. (lien). Évalué à 3.j'aimerais bien voir ou on arrive a imposer ce genre de "bonnes pratiques"
moi chez mes clients.
le routage interne (intranet) a une route par defaut vers /dev/null.
le firewall externe a une seule route (celle par défaut) vers le grand ternet (autrement dit il ne connait pas le réseau interne et ne peut pas y acceder, les seules machines qu'il voit sont les proxy applicatifs qui sont dans son netmask.
seuls les protocoles pour lesquel j'ai installé un proxy applicatif sont utilisables.
c'est lourd, cela oblige a réflechir pour chaque nouvelle demande, mais j'aime bien.
de plus par rapport a l'avantage de l'interface de checkpoint "qui permet de'appliquer les règles necessaires a tous les parefeu sur la route", ben ce ne sert plus a rien puisque AUNCUN traffic en passe plusieurs parefeux :-))
-
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Mr F (page perso, ) le 30/03/2004 à 14:36. (lien). Évalué à 2.Très couteux en cpu (il faut analyser toutes les trames qui passent pour savoir à quoi ça ressemble). Sur un firewall classique, l'opération est impossible. Sur un firewall p4 3Ghz avec un seul client derrière, c'est faisable. Mais ça perd quelque peux de son interrêt :-)
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Fabimaru! (Jabber id, page perso, ) le 30/03/2004 à 14:54. (lien). Évalué à 2.Sur un firewall p4 3Ghz avec un seul client derrière, c'est faisable
Moi, je délègue:
[roger@that roger]$/usr/sbin/traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 216.239.57.99
1 gate (10.0.0.10) 0.664 ms 0.286 ms 0.245 ms
2 bigeye.nsa.gov (10.12.34.56) 0.735 ms 0.422 ms 0.377 ms
[...]--
Pas de bureau 3d libre sans drivers libres!
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par floo () le 30/03/2004 à 15:50. (lien). Évalué à 0.Effectivement Checkpoint (NG) permet de scruter quelques informations dans quelques protocoles
HTTP surtout
TCP, UDP, ICMP ...-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
-
-
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Mathieu Dessus (page perso, ) le 30/03/2004 à 14:21. (lien). Évalué à 1.Les CheckPoint, Netscreen... font beaucoup plus que du simple filtrage de paquets (filtrage de vers, analyse de protocole, VPN entre site et pour utilisteurs nomades), et proposent une intreface unifiée et simple qui permet de gérer toutes ces fonctionnalités.
Bref pour des gens qui ne veulent pas mettre les mains dans le camboui (soit par manque de connaissances, soit par manque de ressources), les solutions commerciales ont certains avantages.
Mais, en ce qui nous concerne (au boulot), c'est du Netfilter.
-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par Zorro () le 30/03/2004 à 15:48. (lien). Évalué à 4.L'intérêt, c'est que j'ai vu une pub sur iTélé, avec des cadres qui déjeunent au resto, et qui se plaignent des virus et des pirates qui nuisent à l'activité économique et surtout à la compétitivité et à l'innovation. Et il y en a un qui se plaint pas, et quand on lui demande pourquoi, il dit que c'est grâce à ses équipements Cisco.
Alors allez tous vous faire voir, bande de pourriture communiste archaïque anti-flexibilité.-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
Posté par earxtacy (Jabber id, ) le 30/03/2004 à 16:30. (lien). Évalué à 1.Tiens t'etais pas A berlin au CCC a la conf sur les exploits cisco ;)
c'etait bien jouissive le screenshot sur un routeur cisco de la nsa...-
[^]Re: Article sur la haute-disponibilité de firewalls sur OpenBSD
-
-
Cette page a été générée par Templeet en 0.1888s (dont 0.0553 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.