======= Proxy ======= Le proxy web de MiNET permet de mettre en cache et de garder une trace des sites web consultés par les adhérents. ===== Description ===== Machine : proxy1, proxy2, et npasserelle10 ((bien que ce ne soit pas rôle principal)) Service : Squid ====== Fonctionnement ====== 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 ==== Mise en cache ==== 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. ==== Connexion ==== 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. ==== Traitement du contenu distant ==== 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. ===== Proxy transparent ===== 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 !!!) ===== Fichiers de configuration ===== Les fichiers de configuration du proxy sont dans /etc/squid et sont : * squid.conf : fichier de configuration de squid ====SNMP==== 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 =====Fichiers journaux===== 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 [[http://www.thegeekstuff.com/2010/07/logrotate-examples/ | 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 ===== Cas particulier : la sauvegarde des logs proxys ===== É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 ... ==== To Do ==== - On constate que nos performances sont pas fameuses sur nos proxys. Sommes nous limités par ceux de la **DISI**? Ou est ce notre conf? On est en droit de se poser des questions... - Améliorer le monitoring depuis **zabbix** : deux solutions principales : squidclient et snmp...