Bug SQUID?

jdh

Pas mal d'à-priori non étayé et de mauvais principes :

il est (très) anormal de redémarrer un firewall de façon régulière !
il est (très) anormal de redémarrer un service tel Squid !
séparer des fonctions PEUT améliorer la fiabilité !
un proxy (Squid) NE DEVRAIT pas être placé sur un firewall !

Le proxy DOIT être séparé du firewall parce que le travail (fonctionnement) est TRES différent d'un firewall, et que c'est la seule façon correcte de stocker les logs de trafic pendant la durée légale.

On peut laisser les autres fonctions sur pfSense car elles sont "de base" : DHCP, portail captif.
(Squid est un package donc est clairement pas de base !)

La complexité de votre schéma et les règles de reboot ne permettent pas de comprendre la nature de vos problèmes : Think Simple dirait les anglophones

ccnet

@nikoo67:

Pourquoi sur une machine séparée? Plus cher, plus de risque de panne, sinon à force de tout séparer, faudrait une machine pour le dhcp, pour le dns, pour le proxy, pour le portail captif… Le but de pfsense n'est il pas de rassembler plusieurs fonctions sur une machine?

De nombreuses idées sur le sujet de la sécurité plutôt fausses.

Le but de pfsense n'est il pas de rassembler plusieurs fonctions sur une machine

On parle bien de sécurité sur ce forum. Pfsense offre un certain nombre de fonctionnalités dans lesquelles on fait ses choix en fonction d'objectifs de sécurité qui varient très sensiblement d'une organisation à une autre. Rassembler toutes ces fonctionnalités sur un produit n'implique en rien qu'il faille l'utiliser de cette façon. La référence, le guide, c'est l'expression des objectifs de sécurité.

sinon à force de tout séparer, faudrait une machine pour le dhcp, pour le dns, pour le proxy, pour le portail captif…

C'est d'ailleurs ce que l'on fait le plus souvent, à différents degrés, dans de nombreuses infrastructures. Principalement pour des raisons de sécurité.

Plus cher

Plus cher par rapport à quoi ? Faire au moins cher a t il un intérêt si les conséquences de l’interruption sont supérieures au coût des équipement ? En matière de traitement des risques il y a longtemps que l'on sait que la réponse est non.

plus de risque de panne

Posez vous la question de l'impact en cas de défaillance d'un système qui fait tourner tous les services d'infrastructures et de sécurité que vous avez listé. Personnellement je préfère perdre le portail captif, ou l'accès à internet plutôt que de perdre tout le réseau. La répartition de ces différentes fonctions sur de multiples systèmes diminue considérablement l'impact du risque. On passe d'un risque brut à un risque résiduel acceptable.
Je pense que vos considérations sont à revoir.
Enfin nous avons à un grand nombre de reprises expliqué ici et ailleurs pour quoi la fonction proxy n'a rien à faire sur le firewall. Les exigences matériels et les consommations de ressources sont assez différentes voire contradictoires pour ces deux équipements. Sans des contraintes de sécurité , notamment l'architecture réseau, qui rendent impropre à l’atteinte de objectifs de sécurités une solution qui concentre toutes les fonctions.
Comme vous le constatez les multiples interactions incontrôlées entre les différents composants rendent votre système instable. C'est exactement le contraire de ce que l'on recherche dans une solution de sécurité.

nikoo67

Bon, vous avez l'air d'avoir eu des soucis de sécurité une fois…

Sinon j'avance dans mon problème.

Le soucis n'a rien à voir avec mon architecture mais avec le matériel.
J'ai remplacé mon boitier pfsense (APU1D4) avec mon ancien(ALIX 2D13) et là aucun soucis. J'ai donc effectué une réinstallation complète de pfsense 2.1.4 et uniquement de squid 2.7.9v4.3.4 et c'est bien le boitier APU1D4 qui pose problème avec squid/pfsense lors d'un reboot.

ccnet

@nikoo67:

Bon, vous avez l'air d'avoir eu des soucis de sécurité une fois…

je suis payé par des clients qui souhaitent maîtriser la sécurité de leur SI.

nikoo67

Hello me revoila.

Après quelques tests, je crois pas me tromper en disant qu'il y a bel et bien un bug entre Squid, pfsense et certaines machines. En particulier avec mon APU1D4. Je pense qu'une initialisation matérielle(genre des cartes réseau) se réalise trop tard par rapport au démarrage de squid et/ou pfsense. D'où le non fonctionnement aléatoire au démarrage de squid.

J'ai résolu mon problème (enfin pour l'instant il ne me pose pas de soucis depuis 8j donc 8 redémarrage) en mettant une fonction php au démarrage après le démarrage de squid: filter_configure();
Ce n'est certes pas le plus "propre" mais cela a le mérite de fonctionner.

Je vous cache pas que je suis un peu déçu des réponses (ou plutôt des non réponses) qui m'ont été donné à mon problème initial. Aucune ne répond à mon problème!!!Que des critiques sur la sécurité…D'où en parti aussi l'interet de ce post, car j'ai 2/3 questions;)
-Quel est mon interet à mettre la freebox en bridge plutot qu'en NAT concernant la fiabilité?La sécurité?(Le NAT étant plutot une sécurité nan?
-Le multi NAT est déconseillé un peu partout. J'ai beau chercher, je ne vois pas d'argument important étant vraiment contre.

-concernant mon architecture, je vois pas trop d'alternative hors multi NAT (comment séparer deux réseaux (Admin et clients) sur un même load balancer (2lignes ADSL) simplement multi NAT)?

-Enfin dernière question: pour améliorer ma sécurité, dois-je enlever les accès HTTP coté WAN à pfsense et mon load balancer? Enlever les réponses au ping coté WAN?. Autres choses? Ces accès étants bien pratiques pour diag une panne à distance…Le piratage à distance est il bien réel?(je présice que les ports ont été déplacés des 443 et 80).

-Concernant le fait d'avoir une même machine pour le proxy et le pare feu, certes je comprends l'interet de le séparer mais un avantage existe quand même pour le mettre au même endroit: si le proxy se crash, le firewall aussi et donc il n'y a pas de risque de fonctionnement d'internet avec un firewall désactivé.
-concernant les logs, je réalise un envoi par mail 1/j vers une adresse mails, donc pas de risque de pertes des logs avec la machine.

jdh

Je vous cache pas que je suis un peu déçu des réponses (ou plutôt des non réponses) qui m'ont été donné à mon problème initial. Aucune ne répond à mon problème!!!Que des critiques sur la sécurité…D'où en parti aussi l'interet de ce post, car j'ai 2/3 questions;)
-Quel est mon interet à mettre la freebox en bridge plutot qu'en NAT concernant la fiabilité?La sécurité?(Le NAT étant plutot une sécurité nan?
-Le multi NAT est déconseillé un peu partout. J'ai beau chercher, je ne vois pas d'argument important étant vraiment contre.

ccnet et moi nous vous avons répondu.

Ces réponses (concordantes comme souvent) ne vous conviennent pas.
Il n'empêche !

ccnet ou moi répondons depuis très longtemps en fonction de notre expérience pratique et en fonction de ce que nous avons lu sur la sécurité.

Au contraire, vos principes sont assez aléatoires. Que dire de votre hypothèse qui n'est pas vérifiée ?
Vous ne vous posez pas de questions sur le matériel : il est plus que probable qu'avec un matériel plus puissant vous ne rencontriez pas ce problème qui me semblent lié au matériel et pas à pfSense ni Squid.

Pour quelles raisons, redémarrez vous vos matériels ?
(Je le faisais avec des serveurs Windows NT en raison de l'instabilité inhérente : ce n'est pas le cas avec pfSense ou Squid pour lesquel j'ai des uptime de plusieurs centaines de jours)

Vous sous-estimez la nécessité de séparer Squid du firewall, sans doute parce que vous ne vous documentez pas assez sur la différence essentielle entre les 2 processus et précisément les besoins mémoire de Squid.

Par ailleurs, par manque de connaissance, vous reprenez des idées "idiotes" et hélas répandues.
Comme exemple, le ping : vous pouvez pinguer google.fr alors pourquoi votre firewall ne devrait pas répondre au ping ?
Il est clair que répondre au ping est utile pour l'analyse de fonctionnement.
MAIS je préconise de n'accepter QUE les seuls paquets icmp/8=echo (cf http://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol ) puisque les autres paquets peuvent éventuellement fournir des informations voire être perturbateur !

Autre exemple, le double NAT fonctionne mais est à éviter dans la mesure du possible parce que plus simple, plus lisible.
Pour de petites sociétés utilisant le FAI Orange, je recommande d'utiliser un modem/bridge (p.e. Dlink DSL320 ~25€) plutôt qu'une Livebox, inutile et onéreuse (3€/mois) = pas de double NAT. Valable aussi chez Sfr, …

ccnet

je crois pas me tromper en disant qu'il y a bel et bien un bug entre Squid, pfsense et certaines machines.

Il faut bien comprendre que Pfsense est développé par une équipe, que Squid l'est par une autre et que les packages le sont par ceux qui le veulent bien, qie le font avec plus ou moins de talent ou d'efficacité. En aucun cas l'équipe de Pfsense ne prend en charge les packages et ne garantie quoi que ce soit. De ce fait l’idée d'installer des composants, par définition non maitrisé, externe à Pfsense est une idée douteuse sur le plan de la sécurité. C'est a minima une prise de risque supplémentaire.

Le NAT étant plutot une sécurité nan?

Oui et non. Plutôt une contribution à la sécurité. Ceci uniquement si aucun des systèmes que le traverse laisse trainer des informations dans les entêtes de différents protocoles. Smtp est un bon exemple. La contribution du nat à la sécurité est la dissimulation de l'architecture de votre réseau interne. Rien de plus. Deux nat successifs ne donnent rien de plus.
Par contre le nat peut poser problème avec certains protocoles (SIP, H223, Ipec, …). Ces problèmes sont parfois pris en charge spécifiquement par la plateforme qui translate. Ne comptez pas sur une livebox pour cela.
Deux translations sont susceptibles de compliquer très singulièrement les choses. Jdh explique par ailleurs d'autres raisons qui font que la traçabilité des flux peut devenir problématique. Bref on évite.

Pour icmp voir la réponse de Jdh.

un avantage existe quand même pour le mettre au même endroit: si le proxy se crash, le firewall aussi et donc il n'y a pas de risque de fonctionnement d'internet avec un firewall désactivé.

Si votre architecte fait que le crash d'un de ces éléments fait disparaitre la protection alors votre architecture et vos solutions sont mauvaises. Dans l'analyse des risques c'est bien sûr un scénario que l'on envisage et de façon conséquente on fait en sorte que la disparition du moyen de contrôle, si il fait disparaitre le contrôle, ne permettre plus le fonctionnement du service contrôlé par cette mesure de sécurité. Plus de proxy : plus d'accès à internet, plus de firewall : plus de flux entrant ni sortant. Sinon c'est trop facile.

dois-je enlever les accès HTTP coté WAN à pfsense et mon load balancer?

Les accès distants à l'administration de ces équipements ne devrait se faire qu'au travers d'un vpn et par une interface situé en interne voire sur un réseau d'administration distinct.

nikoo67

Merci cette fois ci pour les réponses adaptées à mon problème. Je le souligne.

Concernant le redémarrage du matériel, j'ai constaté par mon expérience, qu'à défaut d'être néfaste, cela permet de faire un reset quotidien de tous les processus. Ce qui permet éventuellement de palier un bug sur un programme qui consommerait progressivement de la mémoire par exemple. Cela m'a permit également de déceler ce BUG.

Concernant squid (dont mon but est de faire que du log comme je l'ai dis dans mes premiers posts), le besoin en mémoire est faible dans ce cas.
Concernant mon matos (APU1D4), je suis en pic à 4% d'utilisation CPU…<10% en RAM... De plus, c'est un peu ce type de matos qui est mis en avant sur ce même forum(voir PUB sur cette même page...).
Concernant la séparation Squid pfsense. Je suis d'accord que ce n'est pas inclut mais que vu le nombre de configurations l'utilisant dans pfsense (voir les topics sur ce forum), c'est ambigue. Si on voulait pas le mettre en avant, on ne mettrait pas d'onglet "Packages". J'ai installé perl en cli mais squid via l'interface php. Pourquoi cette distingtion dans ce cas?

Bon je veux pas dénigrer par principe mais plus faire une critique constructive hein!

Ok pour le multi-NAT: donc soucis pour qq protocoles mais sinon, c'est pas la fin monde non plus si je comprends bien (de ce coté le dual wan est bien plus un soucis pour les pbs de protocoles...)

Concernant le ping. Quand je choisi de na pas répondre au ping sur un matos,

Par ailleurs, par manque de connaissance, vous reprenez des idées "idiotes" et hélas répandues.
Comme exemple, le ping : vous pouvez pinguer google.fr alors pourquoi votre firewall ne devrait pas répondre au ping ?

on parle de ping ou de proto ICMP? A ma connaissance que de ping. Nan? Désolé de ma question "idiote" mais si ping correspond à type 8 aller et type 0 retour, c'est un peu toi l'idiot qui n'arrive pas à distinguer ICMP et ping :S Le but de ne pas y répondre étant de ne pas être détéctable par un simple ping sur des IP publiques aléatoire qu'utiliserait des pirates ou autres DDOS ping. Recherche sur google!
Windows server a choisi de pas y répondre par défaut apperement ( http://www.tech2tech.fr/activer-le-ping-sur-windows-serveur-2008-ou-2012/ )

jdh

Concernant ping et icmp, il vous manque des bases.
Un site basique http://fr.wikipedia.org/wiki/Ping_%28logiciel%29
Un site plus précis sur icmp (rfc) : https://tools.ietf.org/html/rfc792 (lire la page 13)
En français : http://www.frameip.com/entete-icmp/

La commande ping utilise les paquets icmp de type 8 et 0.
On peut donc, sans difficulté, accepter, et je le recommande, en réception (WAN) les paquets icmp/8.
Une réponse au ping indiquera facilement qu'un hôte est actif.
(Attention la non réponse n'induit pas que l'hôte est inactif, surtout à distance !)
NB : dans les options de la règle, vous pouvez indiquer un nombre maxi de paquets traités si vous craigniez un DDOS !
exemple : lien http://serverfault.com/questions/414882/incoming-ddos-attack-it-looks-like-an-icmp-attack-so-what-do-i-block

Le site que vous indiquez montre que Microsoft, par choix de défaut, interdit la réponse aux ping (règle par défaut du firewall).
Clairement c'est un réglage ridicule, enfin AMPSHA.
(La première phrase est fausse : il manque "quand le firewall est actif" !).

ccnet

Le but de ne pas y répondre étant de ne pas être détéctable par un simple ping sur des IP publiques aléatoire qu'utiliserait des pirates ou autres DDOS ping

C'est une mesure de protection tout à fait inexistante. Un "pirate" ne s'y prend pas comme cela pour qualifier des cibles potentielles.