Déporter les logs de squid sur une serveur Syslog distant (iView)
-
Bonjour !
Je viens à vous car j'ai un soucis bien particulier. je souhaiterais déporter les logs de squid (url visités par IP etc…) vers iView, untilitaire qui permet de voir les sites visités.
Seul problème, comment faire en sorte que les logs de squid soient visible ? Etant donné que l'intégralité des logs de pfSense sont visibles sur iView.
En espérant avoir une réponse sous peu.
Cordialement!
-
Seul problème, comment faire en sorte que les logs de squid soient visible ? Etant donné que l'intégralité des logs de pfSense sont visibles sur iView.
???
Syntaxiquement, je ne comprends pas ton propos : si l'intégralité des log de pfSense est visible sur iView, alors ça couvre les log Squid ;D
Ou alors ce que tu appelles l’intégralité n'est pas l'intégralité ::)Tu peux configurer Squid pour que les log de Squid (qui ne vont pas dans syslog, messages etc…) soient exportés via rsyslog vers un serveur distant.
Accessoirement, ta problématique va alimenter la liste des preuves qu'il ne faut pas utiliser pfSense en UTM ;D ;D ;D
-
Oh pardon ! ;D Je vais être plus clair, les logs de pfsense passent très bien sur iView mais mon maître de stage voudrais que les logs du package squid soient aussi présent sur iView. Et en retournant la moitié des forums, sites, tutos… RIEN !
L'idée serait de pouvoir avoir la vue sur les logs de squid depuis une interface web simple d'utilisation (iView en quelque sorte) et pouvoir savoir sur quel sites vont les utilisateurs.
-
Squid génère 2 types de logs :
- des logs du service : démarrage, arrêt, erreur, …
- des logs d'accès : access.log
Les premiers sont, naturellement, dans Syslog, tandis que les seconds sont, naturellement, dans le traditionnel fichier access.log.
(C'est important le naturel ...)
Il y a possibilité de configurer Squid pour qu'il envoie les logs d'accès vers syslog.
(Si vous n'avez pas encore trouvé, c'est que vous n'avez pas cherché ... c'est dans les 2 premiers liens de la bonne question sur G.)Mais c'est très certainement une FAUSSE bonne idée :
- en raison du volume ENAUORME, incohérent avec le protocole (son esprit)
- en raison de l'exploitation : les logiciels standard de visu de logs sont prévus pour accéder à access.log et pas à syslog
- en raison de la rotation : le volume impose de faire de la rotation de log (quid de la rotation avec Squid sur firewall)
En fait, c'est la même chose que de placer Squid sur le firewall : c'est une FAUSSE bonne idée.
(Pierre Dac : rien ne sert de penser, il faut réfléchir avant !)NB : les logs de Squid peuvent être examinés ligne à ligne mais, généralement, on les regarde avec des logiciels de type LightSquid, Sarg ou autre ... parce que le détail n'est pas très utile !
Si vous êtes en stage, vous avez aussi le droit d'expliquer les bonnes pratiques à votre maitre de stage ...
-
Il existe plusieurs outils mettant en œuvre une interface graphique permettant de consulter les log de Squid.
Je ne sais pas comment tu fais tes recherches mais il est extrêmement simple avec n'importe quel outil de recherche web de tomber sur Awstats, Squidanalyzer etc…Il y a même dans les packages de pfSense Lightsquid qui rempli exactement cette fonction.
Comme je n'ose pas croire que tu ne l'as pas vu, j'imagine que ta demande est différente mais je ne la comprends toujours pas :-\
-
"En fait, c'est la même chose que de placer Squid sur le firewall : c'est une FAUSSE bonne idée."
Pourquoi est-ce une mauvaise idée d'utiliser squid sur le firewall ? ???
-
Pourquoi est-ce une mauvaise idée d'utiliser squid sur le firewall ? ???
C'est un débat récurent dans cette section du forum :-X
La raison principale, et qui doit être prise en compte avec sérieux, c'est que cette solution est basée sur une approche de type "package" donc que ça ne fait pas partie du noyau de pfSense donc sujet à dysfonctionnements potentiels. D'un autre coté, il faut bien reconnaître que tous les packages ne sont pas suivis de la même manière. au passage à 2.3, l'équipe pfSense a fait un sérieux ménage pour supprimer les packages non maintenus.
Les autres arguments sont du domaine de l'impact en terme de performance et de la sécurité.
De mon point de vue, en terme de performance, c'est juste une information à prendre en compte dans le dimensionnement de ta machine pfSense, avec pour résultat une machine potentiellement très grosses si on considère uniquement les aspects FW.Le point qui me parait plus important d'appréhender, c'est que si tu choisis la solution "package", alors tu as la flexibilité, en terme de configuration, de ce que t'offre le développeur du package 8)
-
Bon j'ai trouvé ! Rien de bien compliqué finalement ;D
-
Le débat 'Squid sur firewall' est récurrent.
Forcément, les arguments s'évaluent en fonction de SES propres critères.
Néanmoins les restrictions à Squid sont assez claires :
- package : aucune garantie, limité aux fonctionnalités incluses
- charge : impact sur le fonctionnement, sur le besoin mémoire.
Face à cela, le proxy dédié offre des avantages nets et clairs :
- aucun impact particulier sur firewall
- fonctionnement tel qu'on le souhaite
- gestion complète et affinée du filtrage, des logs, …
- capacité à respecter la loi de janvier 2006 !
Il est clair que cela exige plus de compétence pour créer un proxy dédié et qu'on ne bénéficie pas de l'interface, mais on fait exactement ce qu'on veut (et sans impact sur le firewall).
Bref c'est à recommander dès qu'il y a un trafic qui commence à devenir important : disons un ligne fibre et 15 utilisateurs ...
Comme souvent, il y a la réponse en 2', puis la réflexion sur la bonne méthode, le bon schéma, ...
Pour revenir au sujet, j'ai répondu, non sur la question qui demandait juste 2' de recherche, mais sur l'esprit, le fond.
Comment allez vous gérer les milliers de lignes de Squid dans syslog ?