4. Questions diverses

Questions diverses

  • A

    Bonjour à tous,

    Je débute depuis peu avec pfSense et je me pose quelques questions.

    Contexte :

    • Un réseau d'une centaine de machines

    • Deux sous-réseaux dont un filtré

    • Pas de service accessible depuis l'extérieur

    • Les postes clients sous Windows et les serveur Windows / Linux

    J'ai parcouru un peu le forum et j'ai eu peur de certaines choses !

    J'ai lu à plusieurs reprises que pour un réseau "actif", il serait préférable de séparer pfSense et le proxy/filtrage ?

    Pour les mises à jour Windows, du coup il vaut mieux installer un serveur WSUS ?

    Question générale, pour des serveurs qui offrent des services internes, est-il nécessaire (mieux) de créer un sous-réseau dédié pour eux ?

    0
  • C

    Quelques éléments de réponse.

    La description est succincte. Je ne suis pas certains de comprendre exactement ce que signifie "Deux sous-réseaux dont un filtré". J'imagine deux /24 séparés par un routeur, par Pfsense ? Que l'un ne peut pas accéder à l'autre sans en comprendre le besoin d'un point de vue fonctionnel. Pures suppositions de ma part qui limitent la pertinence des réponses.

    J'ai lu à plusieurs reprises que pour un réseau "actif", il serait préférable de séparer pfSense et le proxy/filtrage ?

    Nous sommes plusieurs à avoir détaillé à différente reprise les raisons qui nous semble justifier la séparation des deux fonctions qui, surtout avec 100 postes consomment des ressources de façon assez antinomiques.

    Pour les mises à jour Windows, du coup il vaut mieux installer un serveur WSUS ?

    Cela me parait être une bonne idée, surtout vu l'aspect contraignant des mises à jour réalisées depuis le sire Microsoft. C'est surtout du point de vue du confort des utilisateurs. Ensuite si vous avez des configuration très spécifiques, bien standardisées, il n'est pas inutile de ne pas appliquer aveuglément les correctifs Microsoft.

    Question générale, pour des serveurs qui offrent des services internes, est-il nécessaire (mieux) de créer un sous-réseau dédié pour eux ?

    Je ne sais pas donner une seule réponse qui vaille pour toutes les organisations. Je ne pense pas que ce soit ni possible, ni pertinent (de donner une réponse unique). Je ne sais pas quel est le métier de l'entreprise. La réponse est fonction du degré de sensibilité des informations gérées. La seule méthode passe à mon sens par une analyse de risque. Vous pourrez déduire de l’écart entre le risque brut et le niveau de risque résiduel souhaité (c'est celui que vous acceptez) les mesures à mettre en œuvre.

    Segmenter et cloisonner sont des bonnes pratiques de la défense en profondeur. C'est aussi assez structurant. Après il y a des difficultés de mise en œuvre potentiellement, donc coûts et contraintes. C'est plus difficile avec les environnements Microsoft. Pa r exemple le confinement d'un serveur Windows implique qu'il ne soit pas dans un domaine AD, sinon il ne peut pas être confiné et il emporte avec lui des informations qu'on pourrait ne pas vouloir présentes dans une zone de sécurité particulière. Encore une fois c'est un exemple et non une règle de conduite.

    Une dernière chose : instinctivement on considère les menaces externes comme les plus fortes. C'est souvent faux.

    0
  • C

    @aksl:

    Contexte :

    • Un réseau d'une centaine de machines

    • Deux sous-réseaux dont un filtré

    • Pas de service accessible depuis l'extérieur

    • Les postes clients sous Windows et les serveur Windows / Linux

    Je ne sais pas ce que tu entends par sous-réseau  :-[
    C'est un réseau routé ?
    Un réseau dans un autre subnet ?

    [quote]J'ai parcouru un peu le forum et j'ai eu peur de certaines choses !
    J'ai lu à plusieurs reprises que pour un réseau "actif", il serait préférable de séparer pfSense et le proxy/filtrage ?

    Pour une centaine de machines, si l'activité "web" est significative, le proxy va en effet demander pas mal de ressources. Il est préférable de le mettre sur une machine à part. D'autant que si tu veux un jour bénéficier de fail-over ou de load-balancing sur le WAN, le proxy sur pfSense ne sait pas (pour le moment) le faire.

    Pour les mises à jour Windows, du coup il vaut mieux installer un serveur WSUS ?

    C'est toi qui voit. ça n'a pas grand chose à voir avec pfSense ou le proxy:
    si la bande passante utilisée par les multiples mises à jour de tous tes clients Windows ne te dérange pas, un serveur WSUS n'est pas indispensable.
    Mais c'est comme pour le proxy : avec une centaine de machines, ça commence à faire une consommation conséquente sur le WAN et un serveur WSUS serait le bienvenu.

    Question générale, pour des serveurs qui offrent des services internes, est-il nécessaire (mieux) de créer un sous-réseau dédié pour eux ?

    Même point qu'au début du post. C'est quoi pour toi un sous-réseau dans ce contexte ?
    Si ta question est : "vaut-il mieux isoler les serveurs derrière un pare-feu lorsqu'ils sont accédés uniquement depuis le LAN ?"  je dirais que ça dépend du nombre de serveur et des contraintes de sécurité que tu vas retenir.
    Si tu as un seul serveur, tu peux gérer un FW local (FW Windows ou iptables ou autre).
    Si tu as beaucoup de serveurs, un firewall unique permet une gestion plus facile et plus cohérente pour l'ensemble des serveurs.

    0
  • A

    Bonjour,

    Merci pour vos réponses !

    En gros j'ai un réseau en 192.168.1.0/24 qui peut accéder à internet sans filtrage et un réseau en 192.168.2.0/24 quoi doit être filtré.

    Je compte mettre en place du fail-over et du load-balancing sur le WAN (2 box). Donc si les réseaux utilisent le proxy, ils ne pourront pas en bénéficier ?

    Pour les mises à jour Windows je verrai ça un peu plus tard.

    Au niveau des mes serveurs, il 'y a pas vraiment de risques. C'est une école avec un réseau administratif et pédagogique.

    Au niveau de l'architecture ça ferait :

    2 BOX (accès WAN) - pfSense        –----- 192.168.1.0/24
                                                          ------- 192.168.2.0/24 (filtré)

    Derrière, j'ai deux AD, un debian qui doit être accessible depuis les deux réseaux.

    J'essaye de mettre en place une bonne architecture (c'est ma première).

    Merci beucoup  :)

    0
  • C

    @aksl:

    Je compte mettre en place du fail-over et du load-balancing sur le WAN (2 box). Donc si les réseaux utilisent le proxy, ils ne pourront pas en bénéficier ?

    uniquement si ton proxy est sur pfSense.

    Si tu as un proxy "externe", ce n'est pas un problème  ;)

    Sur ton "schéma" réseau, peux-tu préciser comment tes 2 réseaux se connectent à pfSense ?
    Tu as 2 interfaces physique différentes ?
    pfSense fait le routage entre les 2 ?

    0
  • A

    Au final, mon pfSense aura 4 interfaces physiques (si le proxy reste dessus).

    • 1er WAN

    • 2ème WAN

    • 192.168.1.1 pour le réseau 192.168.1.0/24

    • 192.168.2.1 pour le réseau 192.168.2.0/24

    Il y a un routage entre le 1.0/24 et le 2.0/24 mais seulement pour quelques machines (les clients ne doivent pas accéder au réseau administratif, seulement les serveurs).

    Une question peut-être bête, si je sépare le proxy du pfSense :

    • Les postes du réseau 1.0/24 doivent-ils passer par le proxy (même si je ne les filtre pas) ?

    • Ou alors je leur met directement comme gateway l'interface pfSense ?

    En lien avec ça, si je souhaite utiliser une authentification Active Directory sur mon proxy, comment dois-je faire avec deux AD (squid gère-t-il le double AD) ?

    0
  • B

    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

    0
  • A

    @baalserv:

    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

    0
  • B

    @aksl:

    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

    @aksl:

    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 ..

    0
  • C

    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é).

    0
  • A

    Merci pour toutes vos réponses, ça m'aide énormément.

    J'ai fait un schéma rapidos, je dois partir sur quelque chose comme ça ?

    Ce n'est donc pas "sale" que la gw des clients du réseau 1 soit directement le pfSense ?

    0
  • C

    @aksl:

    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 autorise

    La 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 sortant

    Ceci pour éviter des déconvenues lorsque tu voudras faire autre chose que du HTTP/FTP  ;)

    0
  • A

    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

    0
  • C

    @aksl:

    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

    0
  • A

    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) ?

    0
  • C

    @aksl:

    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  ;D

    Autre 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 ?

    0
  • A

    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

    0
  • J

    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)

    0
  • C

    @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_Levels

    Il y a pas mal d'exemples documentés sur le web pour ceux qui se sauraient pas comment mettre ça en œuvre.

    0
  • A

    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 ?

    0
  • C

    Ce n'est vraiment pas le type de solution vers lequel je me serais orienté pour du log Squid mais pourquoi pas…  ::)

    0
  • J

    (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 ...)

    0
  • C

    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.

    0
  • C

    @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.

    0
  • J

    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 !

    0
  • J

    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.)

    0
  • A

    @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 :)

    0
  • T

    @aksl:

    Est-ce un problème de faire ça sur une VM ou vaut-il mieux utiliser un serveur physique ?

    Une VM peut être envisagée pour un environnement de test, même si la présence de la VM peut ne pas faciliter voire erroner certains tests. Pour un environnement de production, une VM devrait être à proscrire.

    @aksl:

    Avec environ une centaine d'IP par jour, quelle taille dois-je prévoir sur le disque dur de la machine ?

    Je ne suis pas familier des environnements Linux, je suis plus spécialisé dans les environnements Windows, toutefois je dirais qu'il n'y a pas besoin d'une capacité démeusuré, sans doute un disque de 60 ou 80 Go devrait suffire. A confirmer par des autorités plus compétentes.

    0
  • C

    @Talwyn:

    …/... toutefois je dirais qu'il n'y a pas besoin d'une capacité démeusuré, sans doute un disque de 60 ou 80 Go devrait suffire. .../...

    Le vrai problème, à mon avis, n'est pas tant l'espace de stockage en lui même (l'espace disque ne coûte pas très cher) mais la manière de conserver ces données si l'obligation est un archivage sur 1 an.

    C'est du log, normalement compressé par le process de rotation.

    Le volume dépend principalement de l’activité des utilisateurs sur le web mais au bout d'un an, ça va faire quelques petits Go, pas de quoi s'inquiéter.
    Mais si tu perds ton disque, plus d'archivage. Donc le point important, c'est soit une redondance (avec du monitoring car il n'y a rien de pire qu'un système de stockage avec du RAID pas surveillé  ;D) et/ou de l'archivage à l'extérieur sur un autre support, ce qui est une des motivation de ceux qui font du rsyslog.

    Puisqu'on est dans le disque:
    Si du cache est utilisé avec Squid, la performance du proxy, spécialement si il y a beaucoup d'utilisation (je devrais dire d'utilisation) est sensible à la performance du disque.
    Sur un système de disque "classique" (HDD), il est de bon ton de séparer les axes des disques qui héberge le cache de ceux qui gère les log (car Squid peut être assez bavard en log, même si on ne parle que de access.log)

    0
  • A

    Je pose cette question car pour le moment je n'ai qu'un serveur de disponible avec un disque HDD de 100 Go.

    Comme vous le dîtes, peut-être que je pourrais séparer Squid et les logs.

    Le mieux à faire serait que je puisse exporter les logs avec le log rotate car à côté j'ai un NAS qui a de la place. Est-ce envisageable et propre comme solution ?

    0
  • C

    @aksl:

    Je pose cette question car pour le moment je n'ai qu'un serveur de disponible avec un disque HDD de 100 Go.

    C'est largement suffisant en termes d'espace disque.

    Comme vous le dîtes, peut-être que je pourrais séparer Squid et les logs.

    Mon point sur la séparation n'est pas le log mais le cache. Non pas que les aspects partitionnement ne soient pas importants (autant anticiper les réactions genre "c'est n'importe quoi"  ;D) mais ce que j'exprimais au sujet de la séparation, c'est que le proxy, si il y a beaucoup d'utilisateurs, est sensible à la latence induite par les I/O disques dus à la lecture du cache si il y a beaucoup d'utilisateurs.

    Du coup, un seul axe (HDD) complique un peu les choses.
    Un SSD est bien plus rapide mais la technologie n'est pas adaptée à ce type d'usage, sauf si tu as un SSD dédié au cache et que tu as prêt à le changer de temps en temps (ce n'est plus très cher)

    Dans tous les cas, ne te prends pas trop la tête avec ça pour le moment car avec HTTPS il y a de mons en moins de cache mais garde le à l'esprit si tu rencontres des problèmes de performance avec Squid.

    Le mieux à faire serait que je puisse exporter les logs avec le log rotate car à côté j'ai un NAS qui a de la place. Est-ce envisageable et propre comme solution ?

    Envisageable ? certainement !
    le mieux ? ça dépend du risque que tu veux couvrir.

    • si c'est de l'archivage de fichier access.log compressés, oui c'est une des bonnes solutions
    • si il s'agit de garantir la sauvegarde du fichier access actif et que tu veux palier au fait qu'il n'y a pas un système de disque redondant (type RAID 1, 5 ou autre) surveillé (1) sur le serveur Squid, alors non ce n'est pas la bonne solution car en cas de crash du disque du serveur Squid, tu perds le contenu du fichier access.
      C'est, entre autres, pour cela que certains utilisent rsyslog: externalisation en temps (presque) réel des fichiers log.

    L'autre usage de rsyslog (mais pas très utile à mon sens pour le proxy) c'est la corrélation: si tes machines sont bien alignées temporellement (NTP), faire du debug avec un fichier de log qui centralise tous les logs, c'est vraiment très pratique  8)

    (1): car rien n'est pire qu'un système RAID sans monitoring  :P

    0
  • A

    En parlant de cache, je recherche un tutoriel sur comment bien sizer son cache car je ne me rends pas trop compte.

    Si vous aviez ça sous la main, je suis preneur :D

    Sinon pour l'exportation, je parle surtout pour l'archivage. C'est-à-dire que les logs sont enregistrés en temps réel sur la machine Squid et lorsqu'il faut les sauvegarder, hop sur le NAS !

    Quand vous dîtes "séparer les axes", ça veut dire quoi concrètement ? Partitionnement ?

    Encore merci :)

    Dès lundi je me lance là-dedans ;)

    0
  • C

    @aksl:

    En parlant de cache, je recherche un tutoriel sur comment bien sizer son cache car je ne me rends pas trop compte.
    Si vous aviez ça sous la main, je suis preneur :D

    par exemple.

    Quand vous dîtes "séparer les axes", ça veut dire quoi concrètement ? Partitionnement ?

    non justement. Le partitionnement n'a pas d'impact réel sur la performance. Ce n'est pas le partitionnement qui est important mais la manière dont celui-ci est fait en fonction des disques.
    Le cache, c'est du fichier sur le disque, donc de la lecture et de l'écriture.
    La performance du disque est liée d'une part au taux de transfert mais également, et surtout dans le cas de lecture "non continue" au temps de positionnement des têtes (qui je le rappelle se déplacent toute en même temps pour les têtes associées à un axe donné - spindle en anglais si tu dois lire de la doc à ce sujet et sur l'importance du "seek time").

    Donc si ton disque doit supporter en même temps le fonctionnement du système, l'écriture du log et gestion du cache Squid, l'impact en termes de performance est sensible.
    Donc il est est souhaitable de :

    • créer une partition dédiée sur un disque dédié
    • de configurer le cache pour qu'il ne prenne pas toute la taille de la partition qui lui est dédiée

    un peu de lecture.

    Encore une fois, c'est intéressant mais pas forcément critique selon le nombre et l'activité des utilisateurs. juste à bien comprendre pour le jour où ça ne va pas bien fonctionner.

    0
  • A

    Sachant que j'ai qu'un disque de disponible pour le moment, j'espère que ça ne sera pas un problème.

    Le mieux à faire ? :

    • 1 partition pour le système et Squid

    • Une partition pour les logs

    0
  • C

    La manière de gérer les partitions dépend des habitudes de chacun et chaque administrateur va pouvoir t'expliquer pourquoi sa méthode est la bonne et toute autre méthode différente n'est pas "la bonne pratique". Je ne vais donc pas m'aventurer sur ce terrain  ;D ;D ;D :-X

    Ma seule suggestion: fais au moins une partition à part pour /var/log  ou pour /var

    0
  • A

    Hm petite question, si le proxy est configuré, que j'arrive à y accéder à partir d'un client mais que c'est particulièrement lent ça peut venir d'où ?

    Même si le site est chargé, il y a encore le petit rond qui tourne en haut.

    J'ai essayé avec plein de fichiers de conf, toujours la même chose (même sur deux machines différentes).

    
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl CONNECT method CONNECT
acl Local_Net src 10.1.0.0/16
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access allow Local_Net
http_access deny all
http_port 3128

# --------------------------------------------
# Mise en tampon de Squid :
# --------------------------------------------
# Par défaut, le tampon de Squid est activé,
# ce qui permet d'accélérer le chargement de certaines pages.
# La taille par défaut est de 100 Mo (situé dans /var/spool/squid3).
# Vous pouvez changer la valeur 100 par ce que vous voulez (par exemple 128 pour 128 Mo) :
# cache_dir ufs /var/spool/squid 1 00 16 256
cache_dir ufs /var/spool/squid3 128 16 256

# Taille maximum de mémoire vive utilisée pour stocker le tampon :
cache_mem 128 MB

# Taille maximum des objets stockés dans le tampon :
maximum_object_size 16 MB

# --------------------------------------------
# Tampon DNS :
# --------------------------------------------
# Par defaut, Squid est configuré pour garder 6 heures le tampon DNS
# dont il a pu résoudre le nom et 5 minutes celui dont il n'a pas pu résoudre le nom DNS.

# Modification du temps de tampon pour la résolution de nom - positive -
positive_dns_ttl 8 hours

# Modification du temps de tampon pour la résolution de nom - négative -
negative_ttl 4 minutes

refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320

# --------------------------------------------
# Messages d'erreur en français :
# --------------------------------------------
error_directory /usr/share/squid3/errors/French
    0
  • C

    Squid est sensible au dimensionnement des ressources et notamment taille du cache.
    Ce document peut vous servir de base : http://wiki.squid-cache.org/SquidFaq/SquidMemory
    Après il peut y avoir d'autres facteurs qui impactent les temps de réponse.

    0
  • A

    Même en étant tout seul sur le réseau et en essayant d'accéder à google ?

    Je n'ai vraiment pas la solution là .. Le rond tourne pendant au moins 1 minute et la page a encore du mal a se charger après.

    0
  • C

    je pense que oui. Après il y a tous les paramètres habituels réseau ….

    0
  • A

    C'est peut-être le cache mais je me suis inspiré d'au moins 10 fichiers de conf trouvés sur internet et imposible ..

    L'accès aux sites est super lent .. je ne sais vraiment pas quoi faire

    0
 

Products

Applications

Support

Services

News

Resources

Company

Our Mission

As host of the pfSense open source firewall project, Netgate believes in enhancing network connectivity that maintains both security and privacy. We also believe everyone should be able to afford it.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2019 Rubicon Communications, LLC | Privacy Policy