Le proxy web de MiNET permet de mettre en cache et de garder une trace des sites web consultés par les adhérents.
Machine : proxy1, proxy2, et npasserelle10 1)
Service : Squid
Le proxy s'intercale entre le site web de destination demandé par le navigateur et le navigateur web du client qui veut contacter le site. Il assure 3 fonctions principales :
La mise en cache se fait sur un support de stockage, en général dans /var/cache/squid/ et des sous-répertoires permettant le tri par hâchage/index sont créés. La mise en cache se fait à l'aide de statistiques sur la fréquentation des pages demandées, la taille des objets à mettre en cache, et/ou parfois d'autres algorithmes de décision. Cette opération est critique au niveau performance pour squid, mais ne devrait pas nécessiter de grosse configuration vu le peu de trafic que nous avons à MiNET comparé à certaines universités par exemple.
Notre proxy récupère les pages au travers du proxy de l'int (qui est configuré en “parent”). Si on fait ça, c'est car le débit en passant par le proxy de l'int est très largement supérieur à celui que l'on peut avoir si le proxy se connecte directement à l'internet.
L'inconvénient de passer par l'INT est que notre proxy ne sert finalement plus à rien. Autant résoudre proxy.minet.net en proxy.int-evry.fr, comme ça on économise la gestion d'une machine et on n'a pas à se garder les logs proxy pendant un an ! Surtout que le proxy de l'INT est capable de supporter la charge des adhérents MiNET.
Il est possible de demander à Squid de traiter les contenus en ré-écrivant les URLs, bloquer les sites qui contiennent certains mots clés, etc . Nous accomplissons cette tâche avec squidGuard qui permet une configuration fine des access-lists et des catégories de contenu (pornographie, violence, forums …).
NB : Ceci (squidGuard) a été désactivé lors de la réinstallation de l'été 2008. Pour le moment, nous ne filtrons rien.
Avant de mettre le nouveau proxy en service, j'ai testé différentes solutions de proxy transparent sans succès.
La première idée était d'utiliser WCCP qui est un protocol propriétaire Cisco pour rediriger le traffic web vers un proxy. Après plusieurs tests, j'ai découvert que l'association proxy/routeur s'effectue correctement mais que le transfert ne s'effectue que lorsque l'adresse de destination est une adresse de l'INT. Je ne sais pas pourquoi et je n'ai pas trouvé de solution.
La deuxième idée était de faire du policy routing. Dans le principe c'est la même chose que WCCP (on redirige un traffic particulier vers le proxy plutôt que vers le prochain routeur). Et j'obtiens les même résultats que pour le WCCP.
J'ai ensuite réfléchi à utiliser bender. Mais comme ce n'est pas un routeur on ne peut pas faire de policy routing. A part dans le vlan d'admin (qui n'est pas censé voir du traffic adhérent) bender n'a pas d'adresse IP (c'est un bridge), on ne peut pas non plus monter de tunnel pour faire transiter le traffic. Et enfin si on réécrit l'adresse IP destination pour faire pointer vers le proxy, alors on perd cette adresse IP et donc on ne peut plus finir le 3 handshake de TCP.
Mais finalement le WCCP a fini par marcher et désormais non seulement le proxy est transparent pour les utilisateurs mais aussi la charge est loadbalancée entre proxy1 et proxy2 et cela automatiquement par le routeur.
Voici les lignes de conf ajoutées à squid :
wccp2_router 157.159.40.1 wccp2_forwarding_method l2 wccp2_return_method l2 wccp2_assignment_method mask wccp2_service standard 0 password=****
Et la ligne à ajouter au routeur :
ip wccp web-cache password * ************************
Le mot de passe étant évidement là pour éviter que quelqu'un d'autre que MiNET installe un proxy transparent (ce serait très ballot !!!)
Les fichiers de configuration du proxy sont dans /etc/squid et sont :
Squid peut être interrogé en SNMP. Cf conf pour la configuration. On peut ensuite grapher avec Cacti le nombre de connections reçues, la mémoire utilisée, etc (voir cacti pour les graphes)
Cf la liste des OIDs sur http://wiki.squid-cache.org/Features/Snmp
Les fichiers journaux sont dans /var/log/squid/ et sont similaires à ceux d'apache :
access.log : fichiers d'accès store.log : fichier d'information sur le stockage des objects cache.log : fichier d'information sur le cache
Nous gardons nos logs un an.
Les logs sont compressés et gérés à l'aide de logrotate. C'est un utilitaire utilisés sur l'ensemble des systèmes Linux. Vous trouverez ici un petit tuto sympa et simple expliquant comment s'en sortir avec logrotate.
Voici la configuration utilisée à MiNET ( située dans /etc/logrotate.d/squid3 ):
/var/log/squid3/*.log {
daily
compress
delaycompress
rotate 5
missingok
nocreate
dateext
sharedscripts
postrotate
test ! -e /var/run/squid3.pid || /usr/sbin/squid3 -k rotate && /etc/squid3/export_log
endscript
}
Les logs sont donc compressés tous les jours, et à ce moment on leur ajoute une date. Ensuite, une fois l'opération de rotation effectuée, un script est exécuté : /etc/squid3/export_log
Ce script envoie via NFS les logs d'accès compressés sur un de nos NAS, où ils sont censés être gardés un an. Les logs uploadés via NFS sont chiffrés via clé GPG.
La clé GPG utilisée est valable 1 ans, elle permet de chiffrer les logs pendant le mandat du président qui a généré la clé et qui doit la garder en sécurité, il est responsable de la clé privée. Il doit la garder et au moment de la passation déchiffrer tout les logs pour les chiffrer avec la clé du nouveau président. Donc au moment de la passation le nouveau président doit générer une nouvelle paire de clé, et remlpacer la clé publique sur les deux proxys et la passerelle :
On importe la nouvelle clé
gpg --import --armor fichier
On signe la nouvelle clé pour pouvoir chiffrer sans que gpg pose la question de la confiance à la clé (et perdre un fichier de log parce que la commande gpg n'était pas censée échouer dans le script export_log)
gpg --sign-key key_id
Puis on utilise le script switch_cipher.sh situé dans /root qui permet de déchiffrer et rechiffrer les logs avec des clés différentes.
Pour récupérer un journal :
gpg --output access.log-20131126.gz --decrypt access.log-20131126.gz.gpg
après avoir téléchargé le fichier de log access.log-20131126.gz.gpg sur votre pc puis utilisez votre clé privé pour déchiffrer.
Une fois que vous avez fini n'oubliez pas de :
shred -uz access.log-20131126.gz
Étant donné la législation actuelle, nous sommes tenus de :
Nous sommes donc dans l'obligation de faire des snapshots de nos datasets de log proxys, et d'envoyer le tout sur l'autres NAS. Néanmoins, le script classique ne convient pas car il journalise. Le script a donc été modifié en svg_log.py afin de :
Le script svg_log.py est disponible sur le gitlab MiNET …