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 ¹⁾

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 :

• mise en cache du contenu du site distant en récupérant le contenu à la demande
• vérification de la validité d'accès du navigateur au proxy : adresse IP, login/mot de passe …
• traitement du contenu distant par un programme interne et/ou externe

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.conf : fichier de configuration de squid

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 :

• Ne pas garder les logs plus d'un an.
• Pouvoir les ressortir quoi qu'il arrive pendant un an.

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 :

• Conserver qu'un seul snapshot de backup
• Envoyer les incréments : il serait bien con de surcharger notre réseau.

Le script svg_log.py est disponible sur le gitlab MiNET …