Demande d'information sur proxy

Support Debian
#21

Non, car il reste le nom de domaine du site et l’URL de la page demandés. Et puis il y a aussi les logs du firewall, où on devrait voir l’adresse de destination originelle (mais pas forcément le nom du site ni l’URL).

Par contre cela me fait penser à un détail : si le proxy se trouve sur le LAN et si la méthode de redirection est du NAT destination, alors il faudra en plus que le proxy renvoie les paquets de réponse via le firewall afin que ce dernier y remette l’adresse IP originelle du site. La méthode “facile” consiste à faire du NAT source en plus dans le firewall, mais cela a l’inconvénient de masquer l’adresse source originelle du poste client qui a fait la connexion. Hé ouais, le NAT c’est la solution de facilité mais ça a toujours des inconvénients. L’autre méthode, c’est encore du routage avancé mais sur le proxy cette fois, et Linux a tout ce qu’il faut.

La plupart du temps, un firewall réseau est en fait un routeur auquel on a ajouté du filtrage et autres bricoles. Là où ça varie, c’est dans ses fonctionnalités et possibilités de configuration en tant que routeur, et notamment s’il peut router sur d’autres critères que l’adresse de destination, et notamment le port de destination. Je précise que je ne connais pas du tout le PIX.

#22

PascalHambourg : merci pour les explications :041

Finalement, voilà ce que je vais faire (en très gros) :
Sur le FW, bloquer le http pour tout le monde, sauf pour le proxy
Et configurer les postes clients en leur indiquant un proxy

C’est pas du tout du proxy transparent, c’est vraiment du bricolage, mais compte tenu de mon environnement, je vais devoir m’adapter…

Je garde ce fil ouvert au cas où j’ai des problèmes avec Squid en lui même :slightly_smiling:

Merci à tous

#23

Un proxy non transparent n’est pas du tout du bricolage. Cela demande de la configuration sur les postes, c’est tout. Au contraire, c’est plutôt le principe du proxy transparent qui est du bricolage.

#24

Alors, me voilà les mains dans le camboui en pleine configuration de Squid.

Bien que très documenté, avec pleins de tuto sur le net, j’ai un petit souci.

Disons que j’ai deux plages d’IP : groupe1 et groupe2

Je souhaiterais n’autoriser le Flash pour le groupe2 que sur une certaine plage horaire. Et donc l’interdire pour le reste du temps.
Et pour le groupe1, l’autoriser tout le temps.

Donc, j’ai crée les acl suivantes :

acl groupe1 src 192.168.1.70-192.168.1.75/32 acl groupe2 src 192.168.1.76-192.168.1.80/32 acl matin time MTWHF 08:00-12:30 acl midi time MTWHF 12:30-14:00 acl soir time MTWHF 14:00-18:30 acl deny_rep_mime_flashvideo rep_mime_type -i video/flv acl deny_rep_mime_shockwave rep_mime_type -i ^application/x-shockwave-flash$

et mes règles d’accès :

#On autorise sur les horaires "midi" http_reply_access allow midi deny_rep_mime_flashvideo http_reply_access allow midi deny_rep_mime_shockwave #On bloque le reste du temps http_reply_access deny deny_rep_mime_flashvideo http_reply_access deny deny_rep_mime_shockwave #Autorisation générale http_access allow plage1 http_access allow plage2 #Bloquage du reste http_access deny all

Je n’arrive pas à lui faire prendre en compte un paramètre supplémentaire qui est la plage IP.
J’ai l’impression que la syntaxe de http_access ne permet pas de prendre “deux” acl en même temps.

Dans ce cas, quelle solution ai-je ?

Merci !

#25

[quote=“will7991”]Alors, me voilà les mains dans le camboui en pleine configuration de Squid.

Bien que très documenté, avec pleins de tuto sur le net, j’ai un petit souci.

Disons que j’ai deux plages d’IP : groupe1 et groupe2

Je souhaiterais n’autoriser le Flash pour le groupe2 que sur une certaine plage horaire. Et donc l’interdire pour le reste du temps.
Et pour le groupe1, l’autoriser tout le temps.

Donc, j’ai crée les acl suivantes :

acl groupe1 src 192.168.1.70-192.168.1.75/32 acl groupe2 src 192.168.1.76-192.168.1.80/32 acl matin time MTWHF 08:00-12:30 acl midi time MTWHF 12:30-14:00 acl soir time MTWHF 14:00-18:30 acl deny_rep_mime_flashvideo rep_mime_type -i video/flv acl deny_rep_mime_shockwave rep_mime_type -i ^application/x-shockwave-flash$

et mes règles d’accès :

#On autorise sur les horaires "midi" http_reply_access allow midi deny_rep_mime_flashvideo http_reply_access allow midi deny_rep_mime_shockwave #On bloque le reste du temps http_reply_access deny deny_rep_mime_flashvideo http_reply_access deny deny_rep_mime_shockwave #Autorisation générale http_access allow groupe1 http_access allow groupe2 #Bloquage du reste http_access deny all

Je n’arrive pas à lui faire prendre en compte un paramètre supplémentaire qui est la plage IP.
J’ai l’impression que la syntaxe de http_access ne permet pas de prendre “deux” acl en même temps.

Dans ce cas, quelle solution ai-je ?

Merci ![/quote]

*** EDIT ***
Bon, je vais me répondre à moi même : mettre un !groupe1 à la fin des règles deny.

#26

Salut à tous

Mon squid3 est installé et a l’air de bien fonctionner.

Maintenant, j’ai des questionnements à propos des consultations des logs.

J’ai choisi sarg, qui malgré quelques critiques, semble être le plus populaire et le plus simple à utiliser.

Pour générer les rapports, je constate qu’il y a deux commandes :

Quelle est la différence entre les deux ? Car de prime abord, j’ai l’impression que ça fait strictement la même chose. Mais si les deux existent, il doit bien y avoir une raison :slightly_smiling:

Ensuite, les fichiers de logs de squid sont soumis au logrotate.
Je ne suis pas très familier avec logrotate. Les différentes documentions que j’ai trouvées expliquent très bien comment paramétrer les rotations. Mais je n’ai pas très bien compris qu’est-ce qui déclenche l’archivage des données : La taille du fichier ou une date ? Est-ce que c’est paramétrable ?

Merci !

#27

Hello :slightly_smiling:

Au boulot on utilise celui-ci : Squidanalyzer

squidanalyzer.darold.net/

Il est moderne et actif.
Faut bien avouer que Sarg est assez moche… :slightly_smiling: