Questions diverses
-
Bonjour,
Vous avez déjà 2 réseaux séparer sous AD
Je pense que le plus simple et le plus sain, est de conserver pf comme routeur/fw avec gestion du multi-wan. Donc 2 wan & 2 lan
Vous ajouter un proxy dédier seulement dans le réseau qui en à besoin, pour l'autre réseau l'ip de l'interface pf dans ce réseau servira de Gateway pour les postes.
Squid peut s'appuyer sur l'AD pour l'authentification des users, mais il vous faut aussi une solution de gestion et d'archivage des logs (squid et pf). Le proxy et le système de logs peuvent être sous forme de VM.
Il serai judicieux également d'utiliser le serveur AD du réseau ou sera le proxy pour déployer Wpad afin de facilité la configuration des navigateurs.
Cordialement
Bonjour,
Le serveur AD du réseau où sera le proxy utilise déjà WPAD, ça a l'air de fonctionner pour le moment.
Qu'appelez vous concrètement un proxy dédié ? Un proxy sur un autre machine que le FW ?
Le système de logs n'est pas géré par squid ?
Merci d'avance
-
Qu'appelez vous concrètement un proxy dédié ? Un proxy sur un autre machine que le FW ?
Oui, un proxy sur une machine dédier (VM ou pas) autre que le fw
Le système de logs n'est pas géré par squid ?
Squid génère beaucoup de log et ne remplace pas un serveur SYSLOG qui lui servira au logs de squid mais éventuellement aux logs de pf ou autre ..
-
Attention avec les logs Squid : http://wiki.squid-cache.org/SquidFaq/SquidLogs
Il faut des outils pour les exploiter correctement.
Par ailleurs la consultation et l'archivage des logs sont impactés par la loi du 6 janvier 1978 (informatique et liberté). -
-
Ce n'est donc pas "sale" que la gw des clients du réseau 1 soit directement le pfSense ?
1 - non seulement ce n'est pas "sale" mais en plus tu n'as pas beaucoup de choix. Donc oui la gateway de ces clients, c'est l'interface de pfSense.
2 - ils peuvent malgré tout utiliser le proxy sur le réseau voisin, il suffit que:
# leur DNS résolve le nom correctement
# le FW les y autoriseLa notion de filtrage (qui encore une fois est géré par Squidguard et pas par Squid) peut s'appliquer de manière différente selon 'IP source du client.
un petit point de détail (qui n'en est pas un ;D)
ton schéma réseau est faux car il n'y a pas de raison que le proxy soit traversé. la gateway par défaut des machines sur le réseau 2 devrait être pfSense également (sur son interface "réseau 2". Le proxy n'est qu'une machine de ce réseau et pa sle point de passage obligatoire de tout le flux sortantCeci pour éviter des déconvenues lorsque tu voudras faire autre chose que du HTTP/FTP ;)
-
D'accord donc pour résumé :
-
Gateway pour réseau 2 : interface pfSense
-
Sur pfSense FW : DROP ALL FROM 80, 433 TO WAN NET / ALLOW FROM ip_proxy:3128 TO WAN NET
J'ai du boulot :D
-
-
Sur pfSense FW : DROP ALL FROM 80, 433 TO WAN NET / ALLOW FROM ip_proxy:3128 TO WAN NET
ALLOW FROM ip_proxy~~:3128~~ TO WAN NET
3128, c'est le port d'écoute du proxy, pas le port source du proxy en tant que client HTTP :P
-
Je vais presque reprendre depuis le début ça va être plus simple.
-
Un serveur pfSense
-
Un serveur squid + squid guard
-
Un serveur pour l'exploitation des logs
Sur Squid, il faut prévoir beaucoup d'espace disque pour la sauvegarde des logs ?
Et une question d'ordre générale, un proxy peut être sur deux domaines (authentifier les utilisateurs de deux domaines) ?
-
-
Un serveur pour l'exploitation des logs
Qu'entends-tu par là exactement ? ???
Sur Squid, il faut prévoir beaucoup d'espace disque pour la sauvegarde des logs ?
ça va vraiment dépendre de ta politique d'archivage et de ton métier (les FAI n'ont pas les même obligations que l'entreprise du coin)
Si tu mets en place une option de filtrage (ce qui est normalement obligatoire, ceci dit au passage), du doit conserver les logs pendant 1 an.
Mais tu dois surtout, si tu envisages de mettre en place de l'authentification, faire une déclaration à la CNIL ;DAutre point: tu peux gérer tes logs directement sur le serveur proxy mais habituellement, lorsqu'il y a une vraie volonté de gestion de ceux-ci, la solution généralement admise est rsyslog sur un serveur en charge de récolter les logs de différentes machines.
Et une question d'ordre générale, un proxy peut être sur deux domaines (authentifier les utilisateurs de deux domaines) ?
Toi tu aimes faire des choses simples ;D ;D ;D
Avec une authentification LDAP dans Squid, je ne pense pas que ce soit simple sans mettre en place des mécanismes de LDAP proxy.
Dans AD et/ou en NTLM je ne sais pas :-[
Il y a peut-être une solution avec Kerberos et un trust (et donc ça devrait marcher avec AD) mais comme ton serveur proxy ne peut rejoindre qu'un seul royaume, le trust est obligatoire (pour autant que je comprenne bien la problématique.Tu as vraiment des utilisateurs dans 2 domaines différents ?
-
Pour le serveur de logs, je parlais d'une solution comme rsyslog par exemple ou alors la solution ELK :)
En effet, je compte conserver les logs pendant une année.
Combien de Go dois-je prévoir sur le disque de Squid ?
Pour les deux domaines, c'est juste à titre d"information car j'ai deux réseaux 1.0/24 et 2.0/24, chacun avec son AD.
Je me demandais juste si j'avais voulu utiliser le proxy avec authentification sur les deux réseaux, quelle aurait été la solution :D
-
Maintes fois écrit sur le forum :
Les logs de Squid NE SONT pas dans syslog !!! (donc rsyslog inefficace)
(Encore une raison pour séparer firewall et proxy)
-
@jdh:
Les logs de Squid NE SONT pas dans syslog !!! (donc rsyslog inefficace)
ça dépend comment tu configures Squid ;)
Par défaut les logs sont plutôt dans /var/log/squid/acess etc… mais rien ne t'empêche de les mettre ailleurs, y compris dans syslog si tu lis le lien ci-dessus.
Et donc facilement véhiculés par rsyslog sur un serveur distant.tu peux également utiliser rsyslog pour dupliquer le contenu du log access de squid sur un rsyslog distant:
http://en.wikipedia.org/wiki/Syslog#Facility_LevelsIl y a pas mal d'exemples documentés sur le web pour ceux qui se sauraient pas comment mettre ça en œuvre.
-
Je vais m'amuser avec la solution ELK moi :)
On m'a présenté ça en cours, ça a l'air pas mal :D
Du coup on est bien d'accord que les postes qui utilisent Squid comme proxy ne peuvent pas faire les mises à jour Windows ?
-
Ce n'est vraiment pas le type de solution vers lequel je me serais orienté pour du log Squid mais pourquoi pas… ::)
-
(Comme d'habitude ….)
Par défaut, les log de Squid sont envoyés dans le fichier /var/log/squid/access.log.
Il est possible de les envoyer vers syslog ... mais c'est très stupide !!!
Pourquoi il est très stupide d'envoyer les logs Squid dans syslog ?
Il y a 2 raisons assez évidentes :- les logiciels classiques d'analyse des logs sont conçus pour trouver les logs à la place par défaut, et si on les configurait pour aller vers syslog, ils vont trouver des lignes inutiles et un format qui n'est pas celui par défaut !
- le volume de ces logs et ENAUUUURME par rapport à syslog qui n'est tout simplement pas conçu pour transférer autant de lignes :
exemple : dans mon entreprise, pour la journée d'hier, c'est 150 ip distinctes, 175.100 lignes dans access.log qui fait et 24 Mo !
Bref, avec juste un peu d'expérience ...
(Comme d'habitude, il faut quelqu'un pour me contredire ... mais il y a la pratique, la bonne ...)
-
Surtout que si on regarde le format les logs de Squid :
1286536309.845 221 192.168.0.227 TCP_MISS/200 4035 GET http://i1.ytimg.com/vi/LFV2ASSoEHI/default.jpg - DIRECT/209.85.153.118 image/jpeg 1286536310.075 452 192.168.0.227 TCP_MISS/200 5067 GET http://i1.ytimg.com/vi/TeYOZBVfnuY/default.jpg - DIRECT/209.85.153.118 image/jpeg
Si on mélange çà avec le fichier syslog habituel, l'exploitation devient pour le moins … délicate. Même si c'est possible en théorie c'est à mon sens inexploitable en pratique.
Il faudrait considérer Sarge. ELK ou encore Graylog ce n'est pas évident comme solution si il ne s'agit que de traiter des logs Squid.
-
@jdh:
(Comme d'habitude ….)
.../...
(Comme d'habitude, il faut quelqu'un pour me contredire ... mais il y a la pratique, la bonne ...)Il ne faut pas te sentir sans arrêt agressé et contredit mais il faut t'y attendre quand même un peu si tu avances avec certitude et en majuscule des choses qui peuvent sembler la vérité absolue et unique à ceux qui n'y regarderaient pas de plus près.
Je suis d'accord, s'il y avait le moindre échange constructif et discussion, que ce n'est pas nécessairement une bonne idée de mettre les logs de Squid dans syslog mais la fonctionnalité existe nativement car c'est parfois une solution pratique.
Par ailleurs, comme je le décris dans mon message précédent, la mise en œuvre d'une duplication des logs de Squid au travers du mécanisme de rsyslog pour les centraliser sur un serveur distant n'impose pas de tout écrire dans syslog ::)
Ce n'est pas la peine de me faire passer pour le perpétuel contradicteur qui n'a pas d'expérience (à peine sous-entendu => il n'y a que ta pratique qui est la bonne) : je réagis juste à ta formule pour le moins abrupte qui pourrait laisser croire qu'il n'y à pas d'alternative à un fichier access local.
-
Je ne me sens pas agressé. Je suis juste consterné !
Je constate qu'EN PERMANENCE,
- je décris de bonnes méthodes d'agir, qui ont fait leur preuve, qui sont efficaces,
- à chaque fois, VOUS (et seulement VOUS) ajoutez un truc A LA CON, qui sans être faux, veut dire l'inverse et ne fait QUE dérouter le novice.
Sur TOUS les sujets, il faut que vous rameniez votre fraise avec une truc débile, et que, d'ailleurs vous ne faites pas !
Comme si il fallait indiquer la totale vérité absolue alors que 99% des gens, juste un peu sensé, ne le fait pas !Ici c'est parfaitement flagrant : personne (de sensé) ne fait passer les logs Squid dans syslog !
Ce n'est pas MA pratique, c'est juste la bonne.
Arrêtez de me contredire sans arrêt car vous induisez en erreur les novices : attitude particulièrement minable de votre part !
-
Les bonnes pratiques sont
- avoir UN serveur proxy; par exemple, Debian + Squid3
- y ajouter Apache2 + Perl + Php
- installer Squid(3) : configurer/tester les ACL, sizer la taille du cache et vérifier que la mémoire est adaptée
- installer SquidGuard : configurer/tester le fichier de conf
- ajouter la blacklist de Toulouse (par exemple), prévoir un script avec crontab pour récup régulière
- tester la page d'erreur
- vérifier/configurer la rotation des logs
- installer un visualiseur de logs, par exemple LightSquid
- s'assurer que l'accès à LightSquid est limité par mot de passe
- ajouter les fichiers de WPAD
Cela donne une machine complète avec gestion des logs inclue.
(Quand on est à l'aise et que l'on a déjà fait, que l'on sait ce qu'on veut, que l'on sait faire les tests nécessaires, il faut entre 1/2 et 1 journée.)
-
@jdh:
Les bonnes pratiques sont
- avoir UN serveur proxy; par exemple, Debian + Squid3
- y ajouter Apache2 + Perl + Php
- installer Squid(3) : configurer/tester les ACL, sizer la taille du cache et vérifier que la mémoire est adaptée
- installer SquidGuard : configurer/tester le fichier de conf
- ajouter la blacklist de Toulouse (par exemple), prévoir un script avec crontab pour récup régulière
- tester la page d'erreur
- vérifier/configurer la rotation des logs
- installer un visualiseur de logs, par exemple LightSquid
- s'assurer que l'accès à LightSquid est limité par mot de passe
- ajouter les fichiers de WPAD
Cela donne une machine complète avec gestion des logs inclue.
(Quand on est à l'aise et que l'on a déjà fait, que l'on sait ce qu'on veut, que l'on sait faire les tests nécessaires, il faut entre 1/2 et 1 journée.)
Est-ce un problème de faire ça sur une VM ou vaut-il mieux utiliser un serveur physique ?
Avec environ une centaine d'IP par jour, quelle taille dois-je prévoir sur le disque dur de la machine ?
Merci à vous tous, pas besoin de vous prendre la tête, c'est déjà très sympa de m'aider :)