Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
wiki:services:proxy [2013/11/25 03:24] benwa |
wiki:services:proxy [2017/05/28 00:43] varens [Fichiers journaux] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | ======= 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' | ||
+ | |||
+ | * mise en cache du contenu du site distant en récupérant le contenu à la demande | ||
+ | * vérification de la validité d' | ||
+ | * 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 / | ||
+ | |||
+ | ==== Connexion ==== | ||
+ | |||
+ | Notre proxy récupère les pages au travers du proxy de l'int (qui est configuré en " | ||
+ | |||
+ | L' | ||
+ | |||
+ | ==== 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, | ||
+ | |||
+ | NB : Ceci (squidGuard) a été désactivé lors de la réinstallation de l' | ||
+ | |||
+ | ===== 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' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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 | ||
+ | |||
+ | < | ||
+ | wccp2_router 157.159.40.1 | ||
+ | wccp2_forwarding_method l2 | ||
+ | wccp2_return_method | ||
+ | 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' | ||
+ | |||
+ | ===== 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:// | ||
+ | |||
+ | =====Fichiers journaux===== | ||
+ | |||
+ | Les fichiers journaux sont dans / | ||
+ | |||
+ | access.log : fichiers d' | ||
+ | store.log : fichier d' | ||
+ | cache.log : fichier d' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | Voici la configuration utilisée à MiNET ( située dans ''/ | ||
+ | |||
+ | < | ||
+ | / | ||
+ | daily | ||
+ | compress | ||
+ | delaycompress | ||
+ | rotate 5 | ||
+ | missingok | ||
+ | nocreate | ||
+ | dateext | ||
+ | sharedscripts | ||
+ | postrotate | ||
+ | test ! -e / | ||
+ | endscript | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Les logs sont donc compressés tous les jours, et à ce moment on leur ajoute une date. Ensuite, une fois l' | ||
+ | |||
+ | Ce script envoie via NFS les logs d' | ||
+ | |||
+ | 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' | ||
+ | < | ||
+ | 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' | ||
+ | < | ||
+ | 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' | ||
+ | * Conserver qu'un seul snapshot de backup | ||
+ | * Envoyer les incréments : il serait bien con de surcharger notre réseau. | ||
+ | |||
+ | Le script '' | ||
+ | |||
+ | <WRAP TODO center round> | ||
+ | ==== 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... | ||
+ | </ |