Configuration de squid3

Support Debian
#1

Après l’installation de la passerelle, j’installe squid3. Viendra ensuite dansguardian.

J’ai besoinde créer une acl pour mon lan
acl monreseau src 172.16.10.0 255.255.255.240

Je l’autorise à sortir sur le net via le proxy
http_access allow monreseau

Jusque là j’ai compris ; enfin je pense :smiley:

Il semble qu’ ensuite il faille configurer iptables de sorte que toutes les requêtes venant du Lan vers le net via le port 80 soient redirigées vers le proxy ; est-ce nécessaire vu que j’ai indiqué au début de mon fichier de conf : http_port 3128 transparent :017

Si c’est nécessaire, voici la commande que je saisirais :
iptables -t nat -A PREROUTING -i eth0 -s 172.16.10.0/28 -p tcp --dport 80 -j REDIRECT --to-port 3128

Mon fichier de configuration /etc/network/interfaces

ifconfig -a

br0 Link encap:Ethernet HWaddr 00:08:a1:6d:be:ef
inet adr:172.16.10.1 Bcast:172.16.10.15 Masque:255.255.255.240
adr inet6: fe80::208:a1ff:fe6d:beef/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7722 errors:0 dropped:0 overruns:0 frame:0
TX packets:9673 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:1123755 (1.0 MiB) TX bytes:6211589 (5.9 MiB)

eth0 Link encap:Ethernet HWaddr 00:17:31:57:ed:a0
inet adr:192.168.1.13 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::217:31ff:fe57:eda0/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9113 errors:0 dropped:0 overruns:0 frame:0
TX packets:7805 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 lg file transmission:1000
RX bytes:6592047 (6.2 MiB) TX bytes:1495321 (1.4 MiB)

eth1 Link encap:Ethernet HWaddr 00:08:a1:6d:be:ef
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7794 errors:0 dropped:0 overruns:0 frame:0
TX packets:8348 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:1239335 (1.1 MiB) TX bytes:6134183 (5.8 MiB)
Interruption:18 Adresse de base:0xe800

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

mon.wlan0 Link encap:UNSPEC HWaddr 1C-BD-B9-8D-82-8C-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:78 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:9710 (9.4 KiB) TX bytes:0 (0.0 B)

wlan0 Link encap:Ethernet HWaddr 1c:bd:b9:8d:82:8c
adr inet6: fe80::1ebd:b9ff:fe8d:828c/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1577 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:186689 (182.3 KiB)

#2

Oui, l’interception (par REDIRECT, DNAT ou TPROXY) est nécessaire : l’option “transparent” ne sert qu’à dire à squid qu’il doit s’attendre à recevoir des requêtes HTTP “normales” (destinées à un serveur web) et pas seulement des requêtes destinées à un proxy comme pour un proxy explicite.

Dans la règle iptables je mettrais plutôt br0 puisque c’est par cette interface que vont arriver les connexion HTTP à intercepter.

#3 
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

çà c’est pour autoriser la lan à se connecter au net

iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3128

ou

iptables -t nat -A PREROUTING -i br0 -s 172.16.10.0/28 -p tcp --dport 80 -j REDIRECT --to-port 3128

çà c’est pour pour monreseau qui se trouve sur le lan dont l’interface est br0. De la sorte je redirige les requêtes adressées au net vers le proxy.

J’ai quand même un souci, je n’ai plus accès à mon serveur-passerelle depuis le lan.

Il me faut certainement autoriser l’accès ? :017

#4

1/ D’une manière générale, je n’ai pas à me casser la tête avec l’arrivée des paquets, mais uniquement avec la sortie vers le net, non ?

2/ Le routage étant effectué sur la livebox vers le lan de ma passerelle me permet de m’y connecter via ssh. Mais je n’ai plus accès à ma passerelle depuis le lan, depuis l’installation de squid3.

3/ dois-je inscrire d’autres règles de filtrages dans iptables ou bien est-ce que je passe à la configuration de danguardians ?

#5

C’est du NAT, pas du filtrage. “Autoriser” n’est pas le terme approprié mais passons (c’est comme dire qu’un pont autorise à traverser une rivière, ou qu’un télescope autorise à voir les cratères de la lune).

Que se passe-t-il exactement ? Sur le port 80 ? Dans ce cas si tu veux éviter que ces connexions soient interceptées il faut exclure son adresse de la règle d’interception avec [mono]! -d [/mono].

Désolé, je ne comprends pas ton dernier message. Pas assez précis pour moi.

#6

Je viens de rentrer.

Je peux me connecter à ma passerelle via le netbook (lan). Il devait s’agir d’un dysfonctionnement passagé. Passons.

Pour le reste, je débarque complètement.

Je découvre squid et je n’ai pas encore découvert dansguardian :smiley:

Donc je me suis tapé la lecture du fichier de conf de squid3 ; j’ai un peu mal aux yeux :open_mouth:

J’en suis à me demander ce qu’il me reste à faire pour rendre ma passerelle fonctionnelle.
Je me rends compte que je dois mette des règles iptables !
Je ne connais pas iptables donc j’apprends en même temps.

Pour la dernière question je vais essayer d’être plus précis à l’avenir

#7

En dehors de la règle d’interception que tu as mise en place, il n’y a pas de lien particulier entre squid et iptables. Ce sont deux fonctionnalités indépendantes.

#8

Donc l’installation et la configuration de squid3 n’ont d’autres but que d’obliger les clients du lan à passer par le proxy.
Le reste se fera dans dansguardian (restriction d’accès à certains sites pour certains comptes, limites horaires,…)

#9

Pour le HTTP, en transparent.
Pour le reste, c’est iptables.
Si tu veux obliger le passage par le proxy pour HTTPS ou tout autre protocole pris en charge par squid (en explicite cette fois), il faut bloquer le trafic HTTPS direct dans la chaîne FORWARD avec iptables.

#10

redirection du port 443 vers le proxy

J’ai rien dans iptables :question: :question: :question:

[code]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination[/code]

#11

J’ai parlé de blocage/filtrage, pas de redirection/interception.
Filtrage DROP/ACCEPT/REJECT = table filter
Redirection DNAT/REDIRECT = table nat
La cible REDIRECT n’est pas valide dans la table filter (table par défaut).

D’autre part, j’ai déjà dit qu’on ne pouvait pas faire de proxy transparent en HTTPS (sauf à faire des choses pas très propres avec les certificats), donc une redirection n’a pas d’intérêt.

Il y a deux options :
a) Laisser passer HTTPS à travers la passerelle
b) Bloquer HTTPS sur la passerelle et forcer les clients à utiliser le proxy explicitement pour les connexions HTTPS.

#12

Non, je veux obliger tout le monde à passer par la passerelle.
Ensuite, je donne à certains le droit de passer ou pas.

Je pensais qu’il fallait rediriger la requête vers le port 443 vers le proxy pour obliger les clients à passer par le proxy !

Donc bloquer https sur la passerelle

Forcer les clients à utiliser le proxy pour le port 443

#13

La première règle bloque bien les connexions HTTPS à travers la passerelle. On aurait pu affiner avec la plage d’adresses source et/ou l’interface d’entrée.

Par contre la seconde règle me laisse perplexe. D’une part la chaîne PREROUTING n’existe pas dans la table filter. D’autre part, je ne vois pas comment tu comptes forcer quelque chose avec ACCEPT.

Je répète : la seule façon propre de forcer les clients à passer par le proxy pour HTTPS c’est de bloquer HTTPS à travers la passerelle et configurer explicitement les navigateurs et autres clients HTTPS sur chaque poste pour passer par le proxy.

#14

Je me suis trompé :

Non, je ne vais pas m’amuser à configurer les postes clients. Le but est que tout se passe sans intervention sur les postes clients. Donc, dans les fichiers de conf.

La redirection du port 443 en sortie devrait obliger les postes clients à passer par le proxy, non ?

#15

Pas de façon transparente, par conception même de SSL/TLS qui sert de transport à HTTPS et dont un des objectifs est d’empêcher ou au moins détecter une interception. Ce serait équivalent à une attaque de type “man in the middle”. Les navigateurs vont râler parce que le proxy ne présente pas les bons certificats.

#16

En clair, çà signifie quoi ?

A ce stade, il me semble nécessaire de faire le point :

ce que je souhaite : contrôler le trafic des postes clients du plus réstrictif (les enfants) au pas restrictif (les adultes).

Prenons un cas d’école :
1/ Un des gosses se balade sur le net (port 443 car google en https) et saisi dans le moteur de recherche “reproduction animale des souris”. Dansguardian (éventuellement couplé à la liste de toulouse) fera son boulot et bloquera les contenus pornographiques.
Donc pas de configuration spéciale du proxy ni de iptables.

2/ Un des gosses veut jouer au poker en ligne avec mon compte bancaire (si si ils peuvent être malin s’il le faut :smiley: ). Là encore c’est dansguardian.

Dans mon esprit, tout le monde peut se connecter au net (donc via port 80 ou 443) et ensuite, les contenus autorisés se définissent dans dansguardian.

Je peux aussi ne pas penser à plein d’autres choses car je ne maîtrise pas iptables et squid. :unamused:

Au passage, dansguardian intervient avant ou après squid ?

1/net---eth0---squid---dansguardian---eth1--lan ou 2/net---eth0---dansguardian---squid---eth1--lan

#17

En clair, cela signifie que HTTPS est basé sur TLS/SSL qui est conçu pour assurer la confidentialité du contenu de bout en bout entre le serveur et le client, et que les intermédiaires (routeur, firewall, proxy…) n’y ont pas accès. Normalement. Même en configurant le proxy explicitement dans le navigateur, le proxy ne fait que relayer la connexion HTTPS sans voir son contenu en clair. Un éventuel filtrage ne peut se baser que sur le nom du site ou son adresse IP, mais pas le reste de l’URL demandé ni le contenu du document renvoyé.

J’ai écrit “normalement”, parce qu’un proxy peut quand même intercepter une connexion HTTPS. Il doit renvoyer un certificat au client et trois cas peuvent se produire.

  • Le certificat ne correspond pas au site demandé, le navigateur devrait afficher une alerte. Si l’utilisateur passe outre, le proxy aura accès au contenu en clair de la connexion.

  • Le certificat correspond au site demandé mais n’est pas reconnu comme valide car il n’a pas été signé par les autorités de certification officielles reconnues par le navigateur. Comme ci-dessus, le navigateur devrait afficher une alerte.

  • Le certificat correspond au site demandé et est reconnu comme valide car signé par une autorité que tu as ajoutée dans le navigateur. Pas d’alerte, le proxy a accès au contenu en clair.

#18

Sur le serveur, comment fait-on ?

Dansguardian peut-il analyser le contenu des pages https ?

Je n’aurais jamais accès aux ordi, tablettes et autres objets de la sorte appartenant aux p’tits copains de mes chérubins !!

#19

Je ne sais pas, je n’ai jamais fait de proxy filtrant. J’imagine qu’il faut mettre en place une liste de noms de sites ou adresses IP de serveurs interdits.

Je ne connais pas les détails mais il me semble que dansguardian ne s’occupe pas du transport, c’est le rôle du proxy auquel il est associé.
Voici néamoins la page du wiki de squid qui explique les tenants et aboutissants de l’interception de HTTPS : http://wiki.squid-cache.org/Features/HTTPS

Dans ce cas, on oublie la configuration du proxy explicite. Soit tu renonces au filtrage d’URL et contenu pour HTTPS, soit tu fais l’interception transparente avec les conséquences décrites dans mon message précédent et le wiki de squid. Connaissant les enfants, cela ne devrait pas les gêner de cliquer frénétiquement sur “je m’en fiche du certificat foireux, affiche-moi ce fichu site !”, à la condition toutefois que le navigateur ne soit pas configuré par défaut pour refuser systématiquement d’afficher le site si le certificat reçu n’est pas valide. Mais à mon avis c’est un très mauvais signal envoyé aux enfants, ça ne peut que les habituer à cliquer machinalement sur “j’accepte” sans lire les messages associés.

#20

J’allais juste te poser la question en me rendant compte que tu y avais répondu avant. Trop fort :wink:

Dans ce cas on avance.

Si je souhaite utiliser le netbook de ma fille. Je vais me taper toutes les restrictions. Pas marrant, çà :confused:
Donc je crée un compte enfant et un compte adulte avec mots de passe sur le netbook.
squid peut-il filtrer l’acheminement des paquets en fonction du compte/session ouvert ?
Du style, c’est papa là, alors tu me fiches la paix avec tes interdictions et tu me laisses passer ou je me fâche .
Si oui, comment faire ? Je n’ai lu sur le net que des explications avec squid en mode non transparent.
Je crains qu’en mode transparent squid ne puisse pas.
Tu confirmes ?