Compression log squid
-
bonjour
je voudrais savoir si il y avait la possibilité de compresser les log du pfsense ?
il y as bien un rotate des log dans le cron daily .
merci
j'ai pas vue d'options dans l'interface de pfsense .
peut etre un scripte a mettre ?
-
Je suis désolé : encore une question qui prouve que le proxy DOIT être séparé du firewall !
Dès que l'on créé un proxy dédié, il est possible (voire aisé) de définir :
- les paramètres de Squid,
- les réglages de SquidGuard, avec le téléchargement régulier de la blacklist de Toulouse,
- la rotation des logs,
- le logiciel de visualisation des logs,
- au besoin, l'authentification des utilisateurs.
On perd un interface web agréable mais on GAGNE en efficacité et rationalité.
C'est une grave erreur que de croire, qu'avec une belle interface web, on va mettre en place aisément le proxy de l'entreprise.
Cela demande pas mal de temps, d'ajustements …
-
@jdh:
Je suis désolé : encore une question qui prouve que le proxy DOIT être séparé du firewall !
Dès que l'on créé un proxy dédié, il est possible (voire aisé) de définir :
- les paramètres de Squid,
- les réglages de SquidGuard, avec le téléchargement régulier de la blacklist de Toulouse,
- la rotation des logs,
- le logiciel de visualisation des logs,
- au besoin, l'authentification des utilisateurs.
On perd un interface web agréable mais on GAGNE en efficacité et rationalité.
C'est une grave erreur que de croire, qu'avec une belle interface web, on va mettre en place aisément le proxy de l'entreprise.
Cela demande pas mal de temps, d'ajustements …Si j'applique stricto-sensu ce que tu exprimes et que j'installe Squid et SquidGuard sur la machine qui fait tourner le firewall mais sans passer par le package pfSense, c'est bien ou pas ???
Comme je ne passe pas par le package, je vais pouvoir configurer tout ce que tu décris… :P ;)
Je suis volontairement un peu taquin mais le coté systématique de "le package proxy sur pfSense c'est le mal" sans avoir de vraie explication de pourquoi ce n'est pas bien ne me parait pas militer efficacement dans cette direction.
Je le regrette d'autant plus que je partage au final, cet avis de principe, à condition que ce ne soit pas systématique. Il y a des situations dans laquelle la "bonne" solution semble être une seule machine qui fait tourner tous les services, à condition d'en comprendre les limitations et risques.-
Si c'est le package Squid qui n'est pas bien, la solution que j'évoque ci-dessus résout le problème
-
Si c'est le principe du proxy sur le FW qui est gênant, il faut expliquer pourquoi, et le seul aspect du profil de charge différent devrait être sérieusement argumenté car dans ce cas, ce n'est au final qu'un problème d'adéquation entre le hardware et la charge attendue et avec les hardware facilement disponible, ce problème n'en est au final pas un, il me semble
L'argument de la sécurité me semble valide lorsque la priorité est de se focaliser sur un service de type firewall. Mais dans ce cas, les services DNS, DHCP, VPN qui sont intégrés à pfSense, ce n'est pas mieux que le proxy ::)
A noter qu'à titre personnel, c'est exactement la direction que j'ai retenu: chez moi le serveur DHCP de pfSense n'est pas celui qui distribue les adresses IP internes et mes clients sur le LAN n'utilisent pas pfSense comme leur DNS, mais je conçois que tout le monde ne soit pas paranoïaque et que des administrateurs déploient, en connaissance cause, le proxy sur la default gateway et ce n 'est pas en leur disant juste "ce n'est pas bien" sans vrai argument que ça va changer non ? ???
-
ca a rien a voir avec une affaire de package
ca a a voir avec l'utilisation des ressources mémoire / réseau/ cpu du serveur
qui sont différentes d'un proxy a un fwet qui se genent l'une l''autre sur l'hote
(pour simplifier)
puisque tu veux du pfsense, pourquoi ne pas installer une machine pfsense, sans être routeur, sans nat sans rien, cliente du réseau, et tu y mets le package proxy dessus
c'est toujours mieux que rien (perso jamais fait)
-
ca a rien a voir avec une affaire de package
je ne suis pas assez expérimenté avec pfSense pour en juger pur le moment donc je suppose que tu as raison mais lorsque je parcours le forum "international", il y a quand même pas mal de problèmes qui sont, me semble t-il, liés au fait que les packages ne suivent pas toujours très bien (en terme de timing) les évolution de pfSense
ca a a voir avec l'utilisation des ressources mémoire / réseau/ cpu du serveur
qui sont différentes d'un proxy a un fw et qui se genent l'une l''autre sur l'hoteC'est un point que je veux bien regarder plus en détail avant de tomber d'accord avec toi.
La difficulté de cette discussion est bien sûr liée au fait que "ça dépende de l'usage" et qu'un FW pour plusieurs centaines d'utilisateurs va demander plus de ressources qu'un FW pour une petite cinquantaine, surtout si on y ajoute des fonctionnalités supplémentaires.Mais:
-
- le firewall (dans sa fonction packet filter) demande assez peu de ressources mémoire et encore moins de CPU. De toutes manières, sur les aspects FW, le point limitant est tout d'abord le débit dont tu disposes coté WAN (en faisant la supposition que coté LAN, c'est plus rapide)
-
- le profile de charge de Squid (surtout avec SquidGuard) peut effectivement changer dans des proportions importantes et il faut faire attention de bien soigner les aspects I/O disque et mémoire ainsi que le CPU. Bref, il faut faire attention à tout ;D mais je ne vois pas en quoi ça entre en conflit avec le profil de charge du FW. Il faut juste vérifier, comme sur toute machine *nix qu'il n'y a pas d'I/O wait et donc pas de swap mais avec les configurations actuellement disponible à moindre coût, il est assez facile de dimensionner ton serveur.
-
là ou tu as raison, c'est que faire tourner autre chose que le FW sur une machine dédiée FW peut impacter la performance de celui-ci si ce n'est pas administré correctement. Mais le point est valide également avec un portail captif qui aurait à gérer des centaines de session, ce n'est pas spécifique à Squid
N'importe quel serveur actuel avec 4 cœurs, 8 à 16 GB de mémoire et quelques disques en RAID 0 pour le cache du proxy (ou du SSD si vraiment tu as des craintes) va être plus que suffisant pour la grande majorité des configurations, à condition de ne pas faire l'erreur de surdimensionner les paramètres de ressources allouées au niveaux des services.
Bref, j'ai beau tourner le problème dans tous les sens, si les contentions hardware sont un problème, il faudrait alors avoir une réponse basée sur la connaissance du hardware de l'utilisateur plutôt qu'une position systématique "il ne faut JAMAIS…"
(pour simplifier)
puisque tu veux du pfsense, pourquoi ne pas installer une machine pfsense, sans être routeur, sans nat sans rien, cliente du réseau, et tu y mets le package proxy dessusJuste pour clarifier, JE ne veux pas installer le proxy sur pfSense et je n'ai pas besoin d'interface graphique pour mon proxy. Mais si c'était le cas, je ne ferais pas ça avec pfSense. un Webmin fait très bien l'affaire pour ceux qui ne peuvent pas se passer d'interface graphique. ;)
-
-
DE TOUTES FACONS c'est encore une fois en train de partir en chaussette, (et surtout en hoprs sujet)
tout le monde fait ce quil veut : mais : ca ne se fait pas point.
tu peux tres bien scotcher deux cables electriques entre eux aau lieu d'utiliser un domino ou un wago
ca va marcher => ca se fait pastu peux très bien emballer dans une poche plastique tes cables reliés de dominos et sceller la poche avec du sparadra
ca va marcher => ca se fait pas, on utilise une boite de dérivationtu peux visser au plafond des livebox dépourvues de dhcp et t'en servir d'AP
.. ca va marcher ET ca se fait pas.tu peux tres bien tout ce que tu veux ..
a part en transparent, (quoi que encore) mais bon, donc , a part en transparent, installer un proxy et SG sur pf est une betise
-
et en ce qui concerne le sujet initial du post,
on ne compresse pas le fichier de prod 'access.log' vu quil est de prod
pour les autres (ceux qui ont subi un rotate)
c 'est a vous de :
- soit les déporter via un script bash en scp
- soit les déporter via un script bash ailleurs sur le disque
- et ensuite de les post-traiter avec une commande bash pour la compression, ou tout aautre post traitement qui vous paraitra utile.
vu que vous administrez un pfsense, vous ne devriez pas avoir de problème pour :
- soit mettre en oeuvre de vous même ce scripting et de le planifier
- soit collecter des bouts de scripts sur google et de les assembler a votre guise
-
merci pour la réponse.
il y as deja un scripte qui transphere sur un autre serveur les log et les compresse .
mais c'est sur le serveur lui même j'ai eu le cas d'un serveur ou les log prenne plein de place ?
notre utilisation de pfsense est un portail captif via le paquet captif portal et squid3
il est déjà derrière un autre par feu proxy .
-
merci pour la réponse.
il y as deja un scripte qui transphere sur un autre serveur les log et les compresse .
mais c'est sur le serveur lui même j'ai eu le cas d'un serveur ou les log prenne plein de place ?
Pourquoi ne dégagez vous pas les logs du serveur une fois qu'ils ont été dupliqué sur le stockage ?
Pourquoi les maintenez vous sur le disque du pare feu? quel est le but? la finalité, de la duplication des données, et de leur rétention sur PF?
-> Ceci est une faille dans la chaine de sécurité
(laisser les archives de logs dessus en front du LAN)
-
il est déjà derrière un autre par feu proxy .
ca doit être charmant..
(mais hors sujet, donc je ne dis rien de plus)