Sauvegarde des logs
-
Tu peux tout à fait utiliser rsyslog en disant à Squid d'envoyer le log dans syslog
http://www.squid-cache.org/Doc/config/access_log/pas pour le cache log cependant mais ça ne présente pas d'intérêt.
Comme tu l'as bien compris, la solution que tu as mis en place (transparent proxy) ne te permet pas de savoir qui consulte quel site. C'est complètement impossible car il n'y a pas d'authentification.
Mais est-ce vraiment obligatoire de fournir cette information nominative ?Proxy transparent = pas de filtrage / log pour HTTPS ;)
-
1er point : syslog :
pfSense utilise (forcément) syslog pour stocker les logs (démarrage, ouverture, arrêt, …) applicatifs ou logs de firewall.
Par voie de conséquence, il est prévu de rediriger ces logs vers un serveur syslog.Cependant, il faut comprendre l'utilisation de syslog : c'est basé sur udp/514 et non sur tcp : c'est un protocole léger, destiné à des petits messages, de fréquence faible.
Squid sait rediriger access.log vers syslog mais ce n'est pas du tout subtil : les lignes dans access.log, pour une entreprise, deviennent énauormes et cela très vite !
Le bon conseil n'est donc pas syslog mais de réfléchir à la rotation des logs (squid -k) : au moment de la rotation des logs on peut transférer un fichier, dans sa totalité !
2ième point : Squid sur proxy :
Abondamment écrit sur le site : ce n'est vraiment pas à conseiller dès que le volume l'exige !
La transparence est incompatible avec l'authentification (en mode web, pas dans le log, contrairement à ce qui est écrit !)
De plus, la transparence ne fonctionne pas avec https (sauf à mettre en oeuvre un procédé déloyal).Puisque vous utilisez la virtualisation, pourquoi ne pas créer votre propre proxy, avec l'espace nécessaire au logs, à la rotation, ... !
N'hésitez pas à récupérer la config du Squid installé ...
En sus, avec ce proxy explicite, vous pouvez filtrez, en toute loyauté, tant http qu'https.
(Il vous faudra mettre en place WPAD pour automatiser la découverte du proxy).
Bref une bonne solution ...Bref 2 mauvais conseils (ou plutôt très incomplets) ne vous informant pas exactement de la réalité ...
-
Bonjour,
Tout d'abord merci pour vos réponses.
En effet j'ai bien conscience qu'il serait préférable de séparer les fonctions proxy/firewall/filtrage. Je l'ai également lu à maintes reprises sur ce forum ;)
N'étant présent qu'a 1/3 temps dans cet établissement j'essaie de faire de façon simple, efficace et bien sur à moindre coût :)
J'aimerais bientôt passé en proxy déclaré pour bien filtré le https etc.. mais bon je manque un peu de temps pour le moment !!Donc je note deux idées :
1- Utiliser syslog pour envoyer les logs reçu dans access.log
2-Effectuer une rotation par exemple 180jours puis transférer le fichier au moment de la rotation sur un NAS par exempleLa deuxième solution me semble intéressante , simplement comment effectuer ce transfert de fichier automatiquement au moment de la rotation ?
Merci
Yoan -
Tout sera bien plus facile à faire sur un proxy dédié !
Passer par syslog est une erreur pratique, compte tenu du nombre important de lignes générées.
De plus, comment un outil de visu, tel LightSquid, pourrait-il retrouver les lignes dans syslog (alors qu'il les attend dans access.log) ?
Comme je l'ai écrit (plusieurs fois), syslog n'est pas conçu pour cet usage !
D'ailleurs vous avez bien conscience que les logs ne doivent pas rester dans pfSense …Ce n'est pas parce qu'il existe un package Squid dans pfSense, qu'il est toujours judicieux de l'utiliser !
Pour mettre une vis, un tournevis est plus adapté qu'un marteau, même si le marteau réussit bien à enfoncer la vis ! -
@jdh:
Bref 2 mauvais conseils (ou plutôt très incomplets) ne vous informant pas exactement de la réalité …
;D ;D ;D
Bon, en même temps ce n'est pas trop grave puisque de toute manière tu es là pour corriger et rétablir LA vérité ;D
@jdh:
Cependant, il faut comprendre l'utilisation de syslog : c'est basé sur udp/514 et non sur tcp : c'est un protocole léger (OUI !) , destiné à des petits messages, de fréquence faible.
:o N'hésite pas à commenter ce point plus en détail et de manière étayée :-X
ça nous informera de ce qu'est exactement la réalité ! ;)Si tu avais expliqué que rsyslog est basé sur UDP, lequel est "sans connexion" et que donc il n'y a pas de garantie que le message arrive, ou que le transport n'est pas sécurisé, ça aurait été crédible. Mais cette considération sur la faible fréquence des messages et de leur taille et donc du volume de données me laisse pour le moins perplexe.
Ou alors c'est parce que tu n'utilises pas cette fonctionnalité de rsyslog, persuadé qu'elle présente vraiment les défauts que tu lui attribues.
Plus sérieusement, rsyslog est vraiment conçu pour traiter des quantités très (je veux dire TRES) importantes de données. C'est d'ailleurs pour cela que c'est de l'UDP, afin de ne pas encombrer encore plus le réseau avec TCP et gagner en performance 8)
Comme tu le dis: bref…
Le point valide de ton commentaire, c'est le traitement des données si le but est de faire de l'affichage via des trucs genre lightsquid. Mais je ne coris pas que ce soit l'objectif.
A noter que rsyslog peut également, coté serveur, écrire dans une base de données, et qu'il existe une flopée d'outil et d’interfaces pour ensuite faire des requêtes dans celles-ci.
Pour compléter le tableau, puisque ma réponse précédente n'était pas complète: il est également possible, mais c'est alors un usage qui à mon avis sort du cadre de ce que j'ai compris du besoin, de connecter les logs Squid à des outils de type Elasticsearch via Logstash. La aussi c'est de la redirection de log dans la conf de Squid. Et la aussi prévu pour une quantité très très conséquente de données.
-
Bonjour à tous,
Encore une fois merci pour vos retours.
En effet j'avais bien lu sur ce forum et d'autre que syslog n'étaient pas fait pour ça.J'ai bien conscience également qu'il faut mieux utiliser un proxy déclaré etc…(mais comme dit précedemment je n'ai pour le moment pas le temps d'appliquer cette solution).
Je venais m'informer d'une autre solution qui m'aurais permis de "sauvegarder" (sur un nas ou autre?) le fichier access.log ?
Il est apparemment possible de copier ce fichier pendant la rotation :Le bon conseil n'est donc pas syslog mais de réfléchir à la rotation des logs (squid -k) : au moment de la rotation des logs on peut transférer un fichier, dans sa totalité !
Comment effectuer ce transfert ?
merci
Yoan -
Je parle de logrotate, qui est capable de faire cela.
Mais c'est sur la base d'une Debian + Squid + SquidGuard + LightSquid + un certain nombre de scripts/réglages : wpad + blacklist de Toulouse + whitelist + …Je concède qu'il faut un peu de temps pour avoir un proxy bien au point ...
Mais c'est utile. -
Salut,
Merci pour vos réponses !
Je vais activer la rotation des logs pour 365 jours pour commencer.
Avec une sauvegarde de la VM au cas ou….Ça devrait suffire pour le moment
Merci
A+ -
Bonjour,
Pour la sauvegarde du fichier access.log et des autres fichiers log, j'ai crée un tache cron avec ce script et installé FileZilla sur un serveur ou machine:
#!/bin/sh
Constantes
HOST=x.x.x.x
LOGIN=
PASSWORD=
PORT=21Connexion
ftp -i -n $HOST $PORT << END_SCRIPT
quote USER $LOGIN
quote PASS $PASSWORDTransfert
cd ./dossier
cd ./$(date +'%Y')
cd ./$(date +'%m')
mkdir ./$(date +'%Y%m%d')
cd ./$(date +'%Y%m%d')
put /var/log/portalauth.log portalauth_SITE_$(date +'%Y%m%d').log
put /var/squid/logs/access.log access_Site_$(date +'%Y%m%d').log
put /var/squid/logs/cache.log cache_SITE_$(date +'%Y%m%d').log
bye
#/usr/bin/killall syslogd
cat /dev/null > /var/squid/logs/access.log
cat /dev/null > /var/squid/logs/cache.log
cat /dev/null > /var/log/portalauth.log
#/etc/rc.d/syslogd restart
END_SCRIPTCela crée une connexion ftp sur mon serveur windows et copie les fichiers dans les dossiers crées précedement.
En rouge, je ne l'ai pas mis car je n'arrivais pas à le faire fonctionner. Ce sont des commandes pour vider les fichiers.
-
Cette méthode est bien sûr à proscrire absolument pour deux raisons.
FTP est un protocole absolument non sûr qui doit être abandonné.
La présence d'éléments d'authentification en clair dans un script est une très mauvaise pratique. Dans toutes les entreprises un peu soucieuse de sécurité on fait la chasse aux développeurs qui écrivent de tels scripts et les politiques de sécurité interdisent le plus souvent explicitement cette pratique.