[Filtrage applicatif] Utilité

captain-chaton

Bonsoir à tous,

Je viens demander conseil car j'aimerai implémenter pfsense dans un petit projet d'entreprise, cela dit, j'ai quelques lacunes avec la notion de filtrage applicatif. En effet certaines choses m'échappent.

Je sais que :

Le filtrage applicatif permet de donner au pare-feu une visibilité au niveau de la couche 7 et prévenir certaines attaques au niveau de cette couche. Cela dit, est-ce que d'autres technologies permettent de remplacer le filtrage applicatif ?
Le filtrage applicatif est-il un incontournable aujourd'hui ? (2016)
Si oui est-ce que pfsense peut faire du filtrage applicatif ? Je me renseigne en parallèle sur de la documentation bien sûr mais si je pouvais avoir vos avis cela me permettrait d'avoir un peu plus de recul.

Car j'hésite entre prendre un pare-feu type appliance cisco ASA, mais pfsense me paraît très bien.

Le seul critère qui me travaille, c'est cette notion de filtrage applicatif..

Merci bien pour vos futures réponses !

Edit : Je vois sur la documentation de pfsense, que le filtrage applicatif peut faire l'objet d'un module complémentaire "ipfw-classifyd". Ce module fonctionne bien ?

ccnet

Vaste sujet !
Pfsense est un firewall réseau et si l'on maintient l'analogie osi, il traite les couches 2, 3 et 4. Pour autant le filtrage applicatif est nécessaire et ce n'est pas, sauf via des packages ce que Pfsense réalise. Il n'y pas de technologie de remplacement. De façon générale un firewall applicatif est un proxy, un mandataire qui exécute le protocole (ou plusieurs) pour lequel il est conçu. Vu sous cet angle on peut admettre qu'un relai smtp est un firewall applicatif pour la messagerie. Son rôle étant, par exemple, le filtrage des pièces jointes malveillantes, des spams et des messages adressés à des destinataires inexistants. J'envisage donc une acceptation plus large du "firewall applicatif". Ensuite il y pas mal de marketing pour packager le tout.
Vous lirez sur ce forum que je ne suis pas un très chaud partisan des packages. J'ai expliqué maintes fois mon point de vue.
L'utilisation du firewall applicatif est pour moi indissociable de la segmentation, cloisonnement du réseau.
Le filtrage applicatif me semble incontournable aujourd'hui. Il ne dispense, pas pour les applications web, de la pratique du développement sécurisé. Il est, par exemple, beaucoup plus efficace d'utiliser des requêtes préparés que de compter sur le firewall applicatif pour lutter contre les injections SQL. Cela dit ce composant peut rendre bien des services. Je vous recommande la lecture de https://www.vultureproject.org/. Vous pourrez même tester un produit Opensource dont les préversions sont très prometteuses.
Sans dépenser une fortune dans du Cisco dont la centaine d'avis de sécurité (dont certains critiques : http://www.lemondeinformatique.fr/actualites/lire-une-faille-critique-corrigee-dans-les-pare-feux-cisco-asa-63892.html ) de ces dernièrs mois n'est pas vraiment appétissante. Cela me ferait réfléchir sur la pertinence de cette dépense.
Pfsense connecté à internet et Vulture dans une dmz et les serveurs web dans une autre serait un schéma à considérer. Vulture et Pfsense ont le même os sousjacent.
Vous pouvez aussi lire avec profit les publications de l'ANNSI.
Je n'ai pas le temps de développer plus avant le sujet. ce sont quelques réflexion en vrac.

chris4916

Ce qui est rigolo, c'est qu'il y a quelques années, l'unique problème était de filtrer les protocoles. Et la vie était du coup assez simple:

tu peux faire du SMTP, du SSH ou du HTTP… ou tu ne peux pas.

Avec les évolutions de certains protocoles et notamment de HTTP, et avec la manie de tout faire passer dans le même protocole, filtrer HTTP ne suffit plus. Il faut maintenant pouvoir filtrer ce qu'on fait avec ce protocole.

ça part d'une idée simple: le web est devenu un tel standard sur internet que HTTP/HTTPS est autorisé pratiquement de partout. Pour éviter d'être bloqué par un firewall quelque part, il suffit d'utiliser HTTP comme couche transport et de réécrire son propre protocole encapsulé dans HTTP.
Et hop ! ça marche 8)

Ah mince, voila qu'ils se mettent à vouloir filtrer le contenu de HTTP :-
Il va falloir inventer autre chose ;D ;D ;D

C'est effectivement, comme l'explique ccnet, une dimension du filtrage applicatif, solutionné au moins partiellement par des proxy et reverse proxy HTTP.

Il y a également une autre dimension couverte par le filtre "de niveau 7" qui consiste à tenter de reconnaître, au niveau des paquets, une application sans s'appuyer sur les ports utilisés.
La difficulté de ce type de solution, c'est que ça s'adresse le plus souvent à l'interception de flux qui n’utilisent pas des ports fixes ou qui usurpent, en quelque sorte, des protocoles existants pour y faire passer autre chose. Et comme ça se base sur de la reconnaissance de patterns, l'efficacité n'est pas aussi grande que sur du filtrage de paquets classique.

Mais ce n'est quand même pas un package: cette fonction de L7 filter est disponible dans le module "traffic shapper" par défaut avec pfSense sans qu'il soit besoin d'installer de package supplémentaire.

Du coup, ta question c'est quoi exactement:

est-ce assez fiable ?
ou
faut-il absolument mettre ça en place ?
ou encore
ni l'un ni l'autre, je voulais parler de filtrage HTTP :P

captain-chaton

Merci pour vos réponses rapides !

Ça m'a permis de mieux comprendre le "pourquoi on fait du filtrage applicatif ?".

Donc pour revenir sur ma question en effet, c'est plus :

Est-ce assez fiable ?
Est-ce indispensable ?
Est-ce facilement maintenable ? (ou nécessite des compétences assez poussées voir très pointues)

Car du coup, j'ai vraiment l'impression que on ne peut plus vraiment se passer de ce type de filtrage. Car en effet un proxy bloque des url, bloques en fonction des heures etc.. Mais ne va pas chercher dans un flux http pour voir ce qu'il s'y trame..

Mais ce n'est quand même pas un package: cette fonction de L7 filter est disponible dans le module "traffic shapper" par défaut avec pfSense sans qu'il soit besoin d'installer de package supplémentaire.

D'accord, donc pfsense peut faire du filtrage applicatif de façon natif ?

En fait, ce qui m'embête c'est que si par la suite je décide de faire du filtrage applicatif, ça serait dommage que j'implémente un pare-feu qui ne puisses faire ce type de filtrage.. Car ça m'obligera à le changer..

Merci pour votre aide.

jdh

Ccnet vous a fourni de très bonnes réponses !

Est ce fiable : il est simple et fiable de disposer d'un firewall et de machines dédiées à des tâches simples et bien définies : proxy http, proxy smtp=relais mail, …
Est ce indispensable : si on veut bien maitriser la charge du firewall, il faut l'alléger de ces tâches qui seront mieux effectués sur les machines dédiées, donc ça devient indispensable à partir d'une certaine taille/charge
Est ce facilement maintenable : plus de machines = plus d'administration, mais machine dédiée=administration plus légère

Donc pfSense devrait se limiter à faire du firewall et on devrait ajouter, selon les besoins, les machines dédiées à la tache de mandataires (=proxy) pour les protocoles prévus.

J'arrête là car je ne discute plus avec l'ergoteur en chef ...

chris4916

@jdh:

Ccnet vous a fourni de très bonnes réponses !
[…]
J'arrête là car je ne discute plus avec l'ergoteur en chef …

??? quel est le problème ce coup-ci ?

C'est juste parce que j'ai ajouté un complément à la réponse précédente pour préciser que le filtrage niveau 7 fait maintenant partie intégrante de pfSense et que ce n'est pas un package ?
Ou parce que je soumets l'idée qu'il y également autre chose des proxy pour faire du filtrage "applicatif" ?

Il est bien évident qu’après une très bonne réponse, ce n'est pas la peine d'en rajouter, n'est-ce pas ? ;)

ccnet

@captain-chaton:

Est-ce assez fiable ?

Oui

Est-ce indispensable ?

Je le pense

Est-ce facilement maintenable ? (ou nécessite des compétences assez poussées voir très pointues)

Avec, pour les solutions qui l'utilisent, la possibilité d'utiliser Oinkmaster la maintenance et l'actualisation des règles est automatisée.

Dont acte pour le "non package".

D'accord, donc pfsense peut faire du filtrage applicatif de façon natif ?

En fait, ce qui m'embête c'est que si par la suite je décide de faire du filtrage applicatif, ça serait dommage que j'implémente un pare-feu qui ne puisses faire ce type de filtrage.. Car ça m'obligera à le changer..

Non. D'où l'idée de séparer les deux fonctionnalités pour des raisons d'architecture réseau aussi. Et donc pas d'adhérence entre les deux composants.

captain-chaton

Bonsoir,

Merci pour tous vos éléments de réponse.

Non. D'où l'idée de séparer les deux fonctionnalités pour des raisons d'architecture réseau aussi. Et donc pas d'adhérence entre les deux composants.

Ah, ce n'est pas possible ? Car juste plus haut Chris me dit l'inverse :

Mais ce n'est quand même pas un package: cette fonction de L7 filter est disponible dans le module "traffic shapper" par défaut avec pfSense sans qu'il soit besoin d'installer de package supplémentaire.

Après je comprends bien votre propos, vous avez pour avis qu'il est nécessaire de garder un firewall au strictos census. C'est à dire un dispositif qui filtre sur les couches 2,3 et 4 et d'installer des filtres applicatifs à proprement dit de façon autonome. Donc selon vous, les appliances que l'on retrouve sur le marché, quelques soit la marques d'ailleurs.

Tout ces firewall qui permettent de faire du filtrage applicatif pour vous ne sont pas une bonne chose ? Il est préférable de séparer le filtrage applicatif du firewall ?

Si oui, cela signifie qu'il faut une machine dédié pour faire guise de filtre pour tous les protocoles que l'on veut filtrer ?

Je vous pose toutes ces questions pour essayer de synthétiser un peu.

PS : Du coup une appliance avec pfsense dessus,est-il possible d'y ajouter les packages qu'il faut si l'on doit faire du filtrage applicatif si cette fonction n'est pas native ?

chris4916

@captain-chaton:

Ah, ce n'est pas possible ? Car juste plus haut Chris me dit l'inverse :

Mais ce n'est quand même pas un package: cette fonction de L7 filter est disponible dans le module "traffic shapper" par défaut avec pfSense sans qu'il soit besoin d'installer de package supplémentaire.

non je ne te dis pas l'inverse, même si certains aimeraient bien que ce soit le cas histoire d'entretenir une polémique stérile ;D ;D ;D

La difficulté vient non pas de la technique mais du vocabulaire.
Llorsque tu dis "filtrage applicatif", chacun met derrière cette formulation le sens qui l'intéresse en fonction de sa compréhension ou du domaine sur lequel il se focalise :

filtrer le contenu d'un protocole identifié pour contrôler par exemple la taille des attachements, la présence de virus, ou l'autorisation d'accès au contenu, c'est du filtrage applicatif puisque tu filtres au niveau de l'application.
Le cheval de bataille dans cette section du forum semble être la lutte systématique contre "n'installez surtout pas de packages sur pfSense", du coup les réponses se focalisent sur cet aspect des choses.
ce que je te fais remarquer, c'est que, au delà du filtrage au niveau des applications (proxy, reverse proxy, MTA etc…) pour lesquelles je n'évoque même pas la moindre considération de savoir comment tu vas implémenter la fonction, il y a une fonctionnalité de filtrage niveau 7 basée sur du "pattern matching" au niveau des paquets et que cette fonction est implémentée nativement dans pfSense. Ce n'est pas un package.
c'est la fonction que tu évoques à la fin de ton premier message et qui a été intégrée dans pfSense car il est bien difficile de mettre en œuvre ce genre de chose ailleurs que sur un boitier qui fait du routage (on parle de réseau ici, et non pas d'application).

Après je comprends bien votre propos, vous avez pour avis qu'il est nécessaire de garder un firewall au strictos census. C'est à dire un dispositif qui filtre sur les couches 2,3 et 4 et d'installer des filtres applicatifs à proprement dit de façon autonome. Donc selon vous, les appliances que l'on retrouve sur le marché, quelques soit la marques d'ailleurs.

Tout ces firewall qui permettent de faire du filtrage applicatif pour vous ne sont pas une bonne chose ? Il est préférable de séparer le filtrage applicatif du firewall ?

Si oui, cela signifie qu'il faut une machine dédié pour faire guise de filtre pour tous les protocoles que l'on veut filtrer ?

C'est un autre débat qui est là aussi un peu biaisé par le vocabulaire mais au moins ce débat là rejoint la marotte locale.

L'idée soutenue par ccnet, et que je partage à 100% d'ailleurs, sans avoir besoin de dire systématiquement "ccnet à toujours raison", c'est que le principe de fonctionnement de pfSense avec des packages qui ne sont pas maintenus par les développeurs de pfSense n'est pas une bonne idée car il y a un risque de désalignement du code et donc un risque de dysfonctionnement sur un composant de ton architecture dont la fonction principale est la sécurité.

Par ailleurs, il est évident que plus tu ajoutes de fonctions sur ce serveur, plus tu augmentes les risques de faille.

Si tu veux appliquer à la lettre la sacro-sainte loi du firewall qui ne fait que du firewall, ce n'est pas pfSense qu'il faut déployer ou alors il faut prendre soin de ne pas activer les services intégrés tels que le DNS, les différents VPN, le portail captif, le serveur DHCP etc…

Ceci étant dit et assimilé, tout est question de compréhension technique et d'appréciation de l'impact et du niveau de risque.

Avec un bagage technique basique, il est préférable de s'en tenir uniquement à pfSense "core", c'est à dire ce que développe "nativement" l'équipe pfSense et d'éviter les packages à cause du risque évoqué plus haut.
C'est à la fois plus simple, plus sûr et plus facile à administrer.

De plus, selon la taille de ton infrastructure, aller dans le sens d'une intégration peut nécessiter un hardware assez conséquent avec pour résultat des impacts, en termes de performance, d'un service sur un autre.

Cela signifie t-il qu'il te faut ensuite un serveur par service ?
Pas du tout, en tous cas à mon avis (que je suis le seul à partager, je sais :P)
C'est une affaire de design. Tu peux très bien, sur ta DMZ, installer sur le même serveur un MTA et un proxy, ou un proxy et un reverse proxy, ou tout à la fois si tu le souhaites et que ton hardware le supporte. Ca demande juste plus de reflexion et de compréhension technique que de déployer une appliance qui fait tout.

Il faut ben comprendre que la ségrégation systématique, si elle apporte un plus indéniable en terme de sécurité théorique, génère de la complexité. Si ton organisation est en mesure d'absorber cette complexité, alors c'est bénéfique. Dans le cas contraire, tu auras une plate-forme intellectuellement parfaite mais difficile à gérer et tu perds le bénéfice théorique. Et c'est là qu'il y a un marché pour les appliances et autre UTM, all-in-one etc...

La vérité absolue à grands coups d'assertions n'existe que rarement.

PS : Du coup une appliance avec pfsense dessus,est-il possible d'y ajouter les packages qu'il faut si l'on doit faire du filtrage applicatif si cette fonction n'est pas native ?

Pour enfin vraiment débattre de cette question, il va falloir que tu quittes le domaine conceptuel du "filtrage applicatif" pour enfin décrire plus en détail ce que tu veux filtrer.
Si c'est du mail ou du HTTP, un MTA ou un proxy externes sont tout indiqués.
Si c'est du L7, je laisse à jdh le soin de te proposer une alternative externe à pfSense et si vous ne trouvez rien, tu peux toujours utiliser la fonction intégrée au FW ;D ;D ;D

PS: personne ne s'est encore plaint que tu n'avais pas rempli le formulaire (j'en suis d'ailleurs surpris ;)) mais quelle est la taille de ton environnement ?

captain-chaton

Bonjour,

Autant pour moi, j'ai mal compris, en effet toutes ces notions de filtrages sont toutes nouvelles pour moi.

PS: personne ne s'est encore plaint que tu n'avais pas rempli le formulaire (j'en suis d'ailleurs surpris ;)) mais quelle est la taille de ton environnement ?

Ah ? Je ne savais pas qu'il fallait remplir un formulaire. Je vais voir cela.

Je vais faire le point pour identifier clairement mon besoin, avec vos conseils je commence à comprendre certaines choses. Je vais prendre le temps de poser tout ça et je reviens vers vous.

Concernant mon environnement, il est composé de 800 personnes

Merci.

chris4916

@captain-chaton:

Concernant mon environnement, il est composé de 800 personnes

Avec ce volume d'utilisateurs, imaginer faire autre chose sur le FW que des services "réseau" va consommer pas mal de ressources, même pour du L7 si il y a beaucoup d'activité.

Et dans tous les cas, il faut un proxy déjà assez conséquent !

ccnet

@captain-chaton:

Concernant mon environnement, il est composé de 800 personnes

Merci.

Une structure de cette taille nécessite plusieurs chose sur le plan de la sécurité. Certes de moyens techniques mais aussi une organisation adaptée, par exemple une PSSI. On peut mettre beaucoup de moyens dans la sécurité du SI, mais sans organisation ce n'est pas efficace.
Techniquement il est évident que vous avez besoin d'une architecture un peu solide, avec les bons cloisonnements, de la redondance éventuellement, une distribution judicieuse des fonctionnalité des différents composants de l'infrastructure. A priori il y beaucoup de travail sur cette infrastructure;
Votre problématique est un tout. Il semble qu'il faille sécuriser l'accès à des ressources et sans doute sécuriser la navigation. Cela passe par proxy, reverse, antivirus, segmentation réseau, sensibilisation utilisateurs, charte signée, règles de bons comportement, etc ….
Ce forum n'est pas le cadre pour traiter un tel chantier.