squid3 : journaliser les visites en https et forcer le passage par le proxy
7 réponses
Francois Lafont
Bonjour à tous,
Je suis en train de tester squid3 pour avoir sur un LAN
un proxy authentifié. Je dispose d'une Debian Wheezy à jour
qui fait office de passerelle par défaut sur le LAN (réseau
IP 172.31.0.0/16). Le serveur fait du masquerading.
C'est donc sur cette machine que j'installe squid3 avec
un serveur MySQL pour sotcker les identifiants des comptes
autorisés à passer le proxy squid3. Pas de problème au
niveau de l'authentification, ça marche bien.
Voici mon fichier /etc/squid3/squid.conf :
#-----------------------------------------------
auth_param basic program /usr/lib/squid3/squid_db_auth --user squid --password squid --plaintext --persist
auth_param basic children 5
auth_param basic realm Veuillez vous authentifier
auth_param basic credentialsttl 5 hours
auth_param basic casesensitive off
acl auth proxy_auth REQUIRED
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl localnet src 172.31.0.0/16
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
Ensuite, je me connecte sur une machine du LAN et je configure
sur le navigateur (Iceweasel) le proxy : j'indique au navigateur
de passer par le proxy (qui est aussi la gateway) ie l'IP
172.31.0.1 sur le port 3128 pour le http et le https etc.
Ça fonctionne dans le sens où, à partir de là, si je cherche
à surfer sur le web, j'ai bien une fenêtre me demandant de
m'authentifier. Si je réponds mal je me fais jeter, sinon
ça passe.
1. Mon premier problème est que dans le fichier de log
/var/log/squid3/access.log, je ne vois aucune trace des
visites sur les sites en http*s*.
Par exemple, si je vais sur facebook (en https) et que je
me connecte même sur le site, le fichier de log ne contient
que ces 3 pauvres lignes :
1400809355.077 83 172.31.100.144 TCP_MISS/204 409 POST http://safebrowsing.clients.google.com/safebrowsing/gethash? test1 DIRECT/173.194.41.166 application/octet-stream
1400809355.174 58 172.31.100.144 TCP_MISS/200 919 POST http://ocsp.digicert.com/ test1 DIRECT/93.184.220.29 application/ocsp-response
1400809369.521 59 172.31.100.144 TCP_MISS/200 919 POST http://ocsp.digicert.com/ test1 DIRECT/93.184.220.29 application/ocsp-response
En revanche, quand c'est du http, tout est bien dans le
fichier de log. Est-il possible de loguer les urls visitées
en https ? D'après mes recherches sur le web, ça semble
impossible du fait que justement https est crypté, sauf
en utilisant une technique de « pirate » appelée le
man-in-the-middle. Est-ce correct ? Loin de moi, l'idée
de vouloir jouer les pirates. ;) En revanche je me disais
que les tous premiers échanges entre le client et le serveur
quand on cherche à contacter https://www.facebook.com/ n'étaient
pas cryptés et qu'on pouvait espérer avoir une ligne indiquant
que l'utilisateur a visité https://www.facebook.com dans le
fichier de log. Je me trompe ?
Je ne suis vraiment pas un expert dans squid que je découvre
un peu pour la première fois, mais il me semble que dans les
entreprises, ils arrivent bien à interdire facebook à leurs
employés. Cela ne se paramètre pas via le proxy ? Ils bloquent
simplement des IP de destinations sur les routeurs ?
2. Enfin, si au niveau du navigateur, je lui indique
de ne *pas* utiliser de proxy, les requêtes passent.
Je souhaiterais que ça (les requêtes http et https)
ne passe pas autrement que via le proxy (qui requiert
l'authentification). Alors, j'ai pu voir ce genre
de choses sur le web :
à faire sur le proxy/passerelle. Cela va attraper les
paquets tcp port 80 et 443 et les rediriger vers le port
3128, autrement dit vers le proxy. Et du coup, j'obtiens
ce que je veux. Mais si on cherche à consulter un serveur
en http (ou https) qui écoute sur le port 8080 (par exemple)
alors on va pouvoir passer outre le proxy. Comment peut-on
faire ? Faut-il rediriger tous les ports tcp vers le
3128 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
ST
On 2014-05-23, Francois Lafont wrote:
... En revanche je me disais que les tous premiers échanges entre le client et le serveur quand on cherche à contacter https://www.facebook.com/ n'étaient pas cryptés et qu'on pouvait espérer avoir une ligne indiquant que l'utilisateur a visité https://www.facebook.com dans le fichier de log. Je me trompe ?
Oui. C'est même pour cela qu'on ne peut pas faire de VirtualHost en HTTPS, puisque le certificat dépend du hostname et le hostname est crypté.
à faire sur le proxy/passerelle. Cela va attraper les paquets tcp port 80 et 443 et les rediriger vers le port 3128, autrement dit vers le proxy. Et du coup, j'obtiens ce que je veux. Mais si on cherche à consulter un serveur en http (ou https) qui écoute sur le port 8080 (par exemple) alors on va pouvoir passer outre le proxy. Comment peut-on faire ? Faut-il rediriger tous les ports tcp vers le 3128 ?
Tous les ports TCP ne sont pas forcément du HTTP(S) ou un protocole pris en charge par Squid.
En fait, quand on veut commencer à limiter l'accès à Internet, on procède de façon inverse: on interdit tout et on autorise explicitement ce qu'on veut bien laisser passer.
Un site web qui ne passerait pas sur le port 80 pour contourner un proxy ne devrait donc pas marcher du tout.
-- François la sens-tu qui se glisse dans ton cul, la quenelle ?
On 2014-05-23, Francois Lafont <francois.lafont@nospam.invalid> wrote:
... En revanche je me disais
que les tous premiers échanges entre le client et le serveur
quand on cherche à contacter https://www.facebook.com/ n'étaient
pas cryptés et qu'on pouvait espérer avoir une ligne indiquant
que l'utilisateur a visité https://www.facebook.com dans le
fichier de log. Je me trompe ?
Oui. C'est même pour cela qu'on ne peut pas faire de VirtualHost en
HTTPS, puisque le certificat dépend du hostname et le hostname est
crypté.
à faire sur le proxy/passerelle. Cela va attraper les
paquets tcp port 80 et 443 et les rediriger vers le port
3128, autrement dit vers le proxy. Et du coup, j'obtiens
ce que je veux. Mais si on cherche à consulter un serveur
en http (ou https) qui écoute sur le port 8080 (par exemple)
alors on va pouvoir passer outre le proxy. Comment peut-on
faire ? Faut-il rediriger tous les ports tcp vers le
3128 ?
Tous les ports TCP ne sont pas forcément du HTTP(S) ou un protocole pris
en charge par Squid.
En fait, quand on veut commencer à limiter l'accès à Internet, on
procède de façon inverse: on interdit tout et on autorise explicitement
ce qu'on veut bien laisser passer.
Un site web qui ne passerait pas sur le port 80 pour contourner un proxy
ne devrait donc pas marcher du tout.
--
François la sens-tu qui se glisse dans ton cul, la quenelle ?
... En revanche je me disais que les tous premiers échanges entre le client et le serveur quand on cherche à contacter https://www.facebook.com/ n'étaient pas cryptés et qu'on pouvait espérer avoir une ligne indiquant que l'utilisateur a visité https://www.facebook.com dans le fichier de log. Je me trompe ?
Oui. C'est même pour cela qu'on ne peut pas faire de VirtualHost en HTTPS, puisque le certificat dépend du hostname et le hostname est crypté.
à faire sur le proxy/passerelle. Cela va attraper les paquets tcp port 80 et 443 et les rediriger vers le port 3128, autrement dit vers le proxy. Et du coup, j'obtiens ce que je veux. Mais si on cherche à consulter un serveur en http (ou https) qui écoute sur le port 8080 (par exemple) alors on va pouvoir passer outre le proxy. Comment peut-on faire ? Faut-il rediriger tous les ports tcp vers le 3128 ?
Tous les ports TCP ne sont pas forcément du HTTP(S) ou un protocole pris en charge par Squid.
En fait, quand on veut commencer à limiter l'accès à Internet, on procède de façon inverse: on interdit tout et on autorise explicitement ce qu'on veut bien laisser passer.
Un site web qui ne passerait pas sur le port 80 pour contourner un proxy ne devrait donc pas marcher du tout.
-- François la sens-tu qui se glisse dans ton cul, la quenelle ?
Pascal Hambourg
ST a écrit :
Oui. C'est même pour cela qu'on ne peut pas faire de VirtualHost en HTTPS, puisque le certificat dépend du hostname et le hostname est crypté.
Il y a eu une évolution sur ce point, même si ce n'est pas supporté partout.
Extrait de http://fr.wikipedia.org/wiki/Server_Name_Indication "L'extension du protocole TLS, nommée SNI (Server Name Indication), répond à ce problème en envoyant le nom DNS du domaine dans le cadre de la négociation TLS. Cela permet au serveur de choisir le domaine virtuel plus tôt et donc de présenter au navigateur le bon certificat contenant le bon nom DNS. Par conséquent, avec des clients sachant utiliser SNI, une adresse IP unique peut être utilisée pour servir un groupe de domaines pour lequel il ne serait pas facile d'obtenir un certificat commun."
ST a écrit :
Oui. C'est même pour cela qu'on ne peut pas faire de VirtualHost en
HTTPS, puisque le certificat dépend du hostname et le hostname est
crypté.
Il y a eu une évolution sur ce point, même si ce n'est pas supporté partout.
Extrait de http://fr.wikipedia.org/wiki/Server_Name_Indication
"L'extension du protocole TLS, nommée SNI (Server Name Indication),
répond à ce problème en envoyant le nom DNS du domaine dans le cadre de
la négociation TLS. Cela permet au serveur de choisir le domaine virtuel
plus tôt et donc de présenter au navigateur le bon certificat contenant
le bon nom DNS. Par conséquent, avec des clients sachant utiliser SNI,
une adresse IP unique peut être utilisée pour servir un groupe de
domaines pour lequel il ne serait pas facile d'obtenir un certificat
commun."
Oui. C'est même pour cela qu'on ne peut pas faire de VirtualHost en HTTPS, puisque le certificat dépend du hostname et le hostname est crypté.
Il y a eu une évolution sur ce point, même si ce n'est pas supporté partout.
Extrait de http://fr.wikipedia.org/wiki/Server_Name_Indication "L'extension du protocole TLS, nommée SNI (Server Name Indication), répond à ce problème en envoyant le nom DNS du domaine dans le cadre de la négociation TLS. Cela permet au serveur de choisir le domaine virtuel plus tôt et donc de présenter au navigateur le bon certificat contenant le bon nom DNS. Par conséquent, avec des clients sachant utiliser SNI, une adresse IP unique peut être utilisée pour servir un groupe de domaines pour lequel il ne serait pas facile d'obtenir un certificat commun."
Pascal Hambourg
Francois Lafont a écrit :
Est-il possible de loguer les urls visitées en https ?
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du site contenu dans la requête CONNECT du client.
D'après mes recherches sur le web, ça semble impossible du fait que justement https est crypté, sauf en utilisant une technique de « pirate » appelée le man-in-the-middle. Est-ce correct ?
Correct.
2. Enfin, si au niveau du navigateur, je lui indique de ne *pas* utiliser de proxy, les requêtes passent. Je souhaiterais que ça (les requêtes http et https) ne passe pas autrement que via le proxy (qui requiert l'authentification). Alors, j'ai pu voir ce genre de choses sur le web :
L'interception de HTTPS vers un proxy transparent ne marche pas pour les raisons décrites plus haut.
à faire sur le proxy/passerelle. Cela va attraper les paquets tcp port 80 et 443 et les rediriger vers le port 3128, autrement dit vers le proxy. Et du coup, j'obtiens ce que je veux. Mais si on cherche à consulter un serveur en http (ou https) qui écoute sur le port 8080 (par exemple) alors on va pouvoir passer outre le proxy. Comment peut-on faire ? Faut-il rediriger tous les ports tcp vers le 3128 ?
Non. Il faut rediriger les ports des protocoles que le proxy sait gérer et bloquer les autres sauf ceux qu'on veut autoriser.
Francois Lafont a écrit :
Est-il possible de loguer les urls visitées
en https ?
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du
site contenu dans la requête CONNECT du client.
D'après mes recherches sur le web, ça semble
impossible du fait que justement https est crypté, sauf
en utilisant une technique de « pirate » appelée le
man-in-the-middle. Est-ce correct ?
Correct.
2. Enfin, si au niveau du navigateur, je lui indique
de ne *pas* utiliser de proxy, les requêtes passent.
Je souhaiterais que ça (les requêtes http et https)
ne passe pas autrement que via le proxy (qui requiert
l'authentification). Alors, j'ai pu voir ce genre
de choses sur le web :
L'interception de HTTPS vers un proxy transparent ne marche pas pour les
raisons décrites plus haut.
à faire sur le proxy/passerelle. Cela va attraper les
paquets tcp port 80 et 443 et les rediriger vers le port
3128, autrement dit vers le proxy. Et du coup, j'obtiens
ce que je veux. Mais si on cherche à consulter un serveur
en http (ou https) qui écoute sur le port 8080 (par exemple)
alors on va pouvoir passer outre le proxy. Comment peut-on
faire ? Faut-il rediriger tous les ports tcp vers le
3128 ?
Non. Il faut rediriger les ports des protocoles que le proxy sait gérer
et bloquer les autres sauf ceux qu'on veut autoriser.
Est-il possible de loguer les urls visitées en https ?
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du site contenu dans la requête CONNECT du client.
D'après mes recherches sur le web, ça semble impossible du fait que justement https est crypté, sauf en utilisant une technique de « pirate » appelée le man-in-the-middle. Est-ce correct ?
Correct.
2. Enfin, si au niveau du navigateur, je lui indique de ne *pas* utiliser de proxy, les requêtes passent. Je souhaiterais que ça (les requêtes http et https) ne passe pas autrement que via le proxy (qui requiert l'authentification). Alors, j'ai pu voir ce genre de choses sur le web :
L'interception de HTTPS vers un proxy transparent ne marche pas pour les raisons décrites plus haut.
à faire sur le proxy/passerelle. Cela va attraper les paquets tcp port 80 et 443 et les rediriger vers le port 3128, autrement dit vers le proxy. Et du coup, j'obtiens ce que je veux. Mais si on cherche à consulter un serveur en http (ou https) qui écoute sur le port 8080 (par exemple) alors on va pouvoir passer outre le proxy. Comment peut-on faire ? Faut-il rediriger tous les ports tcp vers le 3128 ?
Non. Il faut rediriger les ports des protocoles que le proxy sait gérer et bloquer les autres sauf ceux qu'on veut autoriser.
Francois Lafont
Bonjour,
Merci à tous les deux pour vos réponses.
Le 23/05/2014 10:10, Pascal Hambourg a écrit :
Est-il possible de loguer les urls visitées en https ?
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du site contenu dans la requête CONNECT du client.
Dans mon exemple de facebook donné dans mon premier message, je ne disposais même pas du nom de domaine (la simple chaîne "facebook" n’apparaissait même pas dans les 3 lignes que j'avais obtenues dans le log).
Y a-t-il une configuration particulière à mettre en place au niveau du squid.conf pour obtenir au moins le nom de domaine ?
-- François Lafont
Bonjour,
Merci à tous les deux pour vos réponses.
Le 23/05/2014 10:10, Pascal Hambourg a écrit :
Est-il possible de loguer les urls visitées
en https ?
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du
site contenu dans la requête CONNECT du client.
Dans mon exemple de facebook donné dans mon premier
message, je ne disposais même pas du nom de domaine
(la simple chaîne "facebook" n’apparaissait même pas
dans les 3 lignes que j'avais obtenues dans le log).
Y a-t-il une configuration particulière à mettre
en place au niveau du squid.conf pour obtenir au
moins le nom de domaine ?
Est-il possible de loguer les urls visitées en https ?
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du site contenu dans la requête CONNECT du client.
Dans mon exemple de facebook donné dans mon premier message, je ne disposais même pas du nom de domaine (la simple chaîne "facebook" n’apparaissait même pas dans les 3 lignes que j'avais obtenues dans le log).
Y a-t-il une configuration particulière à mettre en place au niveau du squid.conf pour obtenir au moins le nom de domaine ?
-- François Lafont
Francois Lafont
Le 23/05/2014 13:20, Francois Lafont a écrit :
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du site contenu dans la requête CONNECT du client.
Dans mon exemple de facebook donné dans mon premier message, je ne disposais même pas du nom de domaine (la simple chaîne "facebook" n’apparaissait même pas dans les 3 lignes que j'avais obtenues dans le log).
Ah, en fait c'est parce que les lignes en question n'apparaissent qu'une fois le navigateur fermé, or je n'allais pas jusque là dans mes tests.
-- François Lafont
Le 23/05/2014 13:20, Francois Lafont a écrit :
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du
site contenu dans la requête CONNECT du client.
Dans mon exemple de facebook donné dans mon premier
message, je ne disposais même pas du nom de domaine
(la simple chaîne "facebook" n’apparaissait même pas
dans les 3 lignes que j'avais obtenues dans le log).
Ah, en fait c'est parce que les lignes en question
n'apparaissent qu'une fois le navigateur fermé, or
je n'allais pas jusque là dans mes tests.
Non. Le proxy ne peux connaître que le nom de domaine ou l'adresse IP du site contenu dans la requête CONNECT du client.
Dans mon exemple de facebook donné dans mon premier message, je ne disposais même pas du nom de domaine (la simple chaîne "facebook" n’apparaissait même pas dans les 3 lignes que j'avais obtenues dans le log).
Ah, en fait c'est parce que les lignes en question n'apparaissent qu'une fois le navigateur fermé, or je n'allais pas jusque là dans mes tests.
-- François Lafont
Francois Lafont
Bonsoir
Clairement il va falloir que je potasse mes régles iptables mais je pense qu'avec les conseils que l'on m'a donnés, je me débrouillerai.
Il me reste juste un truc que je n'arrive pas à m'expliquer. Avec la conf que j'ai donné dans mon premier message, si je configure mon navigateur (FF) pour qu'il utilise le proxy et avec pour page d'accueil https://www.google.fr, alors pas de souci : je dois m'authentifier dès l'ouverture de FF et une fois que c'est fait, je suis sur Google. Je peux surfer et me rendre par exemple sur https://fr-fr.facebook.com via une requête google etc. etc. Pas d'anomalie constatée.
Maintenant, si je décide simplement de changer ma page d'accueil sur FF en mettant https://fr-fr.facebook.com à la place du https://www.google.fr précédent, que je ferme mon FF et que je le ré-ouvre... alors là ça mouline indéfiniment, à aucun moment le navigateur ne me demande de m'authentifier et la page d'accueil facebook ne s'affiche jamais. J'ai alors juste ça dans le log pendant que ça mouline :
Si je stoppe FF dans son chargement vain de la paga d'accueil (sans fermer l'application) et que je rentre à la main https://www.google.fr/ dans la barre d'adresse, alors là j'ai bien une demande d'authentification et ça semble bien fonctionner une fois que je suis authentifié. Mais par contre, toujours sur cette même session où je suis désormais authentifié, si je surfe (via une recherche google etc.) pour aboutir au site de facebook, alors là ça mouline à nouveau.
Bref, le simple fait de changer la page d'accueil de mon FF afin de passer de https://www.google.fr/ à https://fr-fr.facebook.com semble lui poser problème.
Est-ce que vous avez une idée de pourquoi ?
-- François Lafont
Bonsoir
Clairement il va falloir que je potasse mes régles iptables
mais je pense qu'avec les conseils que l'on m'a donnés, je
me débrouillerai.
Il me reste juste un truc que je n'arrive pas à m'expliquer.
Avec la conf que j'ai donné dans mon premier message, si
je configure mon navigateur (FF) pour qu'il utilise le proxy
et avec pour page d'accueil https://www.google.fr, alors pas
de souci : je dois m'authentifier dès l'ouverture de FF et
une fois que c'est fait, je suis sur Google. Je peux surfer
et me rendre par exemple sur https://fr-fr.facebook.com via
une requête google etc. etc. Pas d'anomalie constatée.
Maintenant, si je décide simplement de changer ma page
d'accueil sur FF en mettant https://fr-fr.facebook.com
à la place du https://www.google.fr précédent, que je
ferme mon FF et que je le ré-ouvre... alors là ça mouline
indéfiniment, à aucun moment le navigateur ne me demande
de m'authentifier et la page d'accueil facebook ne s'affiche
jamais. J'ai alors juste ça dans le log pendant que ça
mouline :
Si je stoppe FF dans son chargement vain de la paga d'accueil
(sans fermer l'application) et que je rentre à la main
https://www.google.fr/ dans la barre d'adresse, alors là
j'ai bien une demande d'authentification et ça semble bien
fonctionner une fois que je suis authentifié. Mais par contre,
toujours sur cette même session où je suis désormais
authentifié, si je surfe (via une recherche google etc.) pour
aboutir au site de facebook, alors là ça mouline à nouveau.
Bref, le simple fait de changer la page d'accueil de
mon FF afin de passer de https://www.google.fr/ à
https://fr-fr.facebook.com semble lui poser problème.
Clairement il va falloir que je potasse mes régles iptables mais je pense qu'avec les conseils que l'on m'a donnés, je me débrouillerai.
Il me reste juste un truc que je n'arrive pas à m'expliquer. Avec la conf que j'ai donné dans mon premier message, si je configure mon navigateur (FF) pour qu'il utilise le proxy et avec pour page d'accueil https://www.google.fr, alors pas de souci : je dois m'authentifier dès l'ouverture de FF et une fois que c'est fait, je suis sur Google. Je peux surfer et me rendre par exemple sur https://fr-fr.facebook.com via une requête google etc. etc. Pas d'anomalie constatée.
Maintenant, si je décide simplement de changer ma page d'accueil sur FF en mettant https://fr-fr.facebook.com à la place du https://www.google.fr précédent, que je ferme mon FF et que je le ré-ouvre... alors là ça mouline indéfiniment, à aucun moment le navigateur ne me demande de m'authentifier et la page d'accueil facebook ne s'affiche jamais. J'ai alors juste ça dans le log pendant que ça mouline :
Si je stoppe FF dans son chargement vain de la paga d'accueil (sans fermer l'application) et que je rentre à la main https://www.google.fr/ dans la barre d'adresse, alors là j'ai bien une demande d'authentification et ça semble bien fonctionner une fois que je suis authentifié. Mais par contre, toujours sur cette même session où je suis désormais authentifié, si je surfe (via une recherche google etc.) pour aboutir au site de facebook, alors là ça mouline à nouveau.
Bref, le simple fait de changer la page d'accueil de mon FF afin de passer de https://www.google.fr/ à https://fr-fr.facebook.com semble lui poser problème.
Est-ce que vous avez une idée de pourquoi ?
-- François Lafont
Francois Lafont
Bonsoir,
Le 23/05/2014 21:56, Francois Lafont a écrit :
Clairement il va falloir que je potasse mes régles iptables mais je pense qu'avec les conseils que l'on m'a donnés, je me débrouillerai.
Voilà le genre de script iptables que j'ai fini par obtenir. Ce script (copié ci-dessous) est indiqué en post-up au niveau de la dernière interface configurée dans le fichier /etc/network/interfaces de l'hôte qui est un routeur/pare-feu NAT avec une interface LAN et une interface WAN (indiquées dans le script). L'hôte fait serveur DNS (via un forwarding), serveur DHCP au niveau du LAN, serveur de temps au niveau du LAN et il fait serveur proxy pour le LAN via Squid3.
Ce script est censé forcer les hôtes qui se trouvent dans le LAN à passer par le proxy Squid3 pour faire du Web. Je trouve que ce n'est pas si facile que ça de faire en sorte que les règles iptables fassent exactement ce que l'on veut qu'elles fassent et je serais très intéressé si vous avez des remarques sur le script ci-dessous. Peut-être ne fait-il pas exactement ce que je veux et peut-être même que j'ai laissé sans m'en rendre compte des trous béants. Si vous avez des remarques, suggestions etc. je suis preneur.
Clairement il va falloir que je potasse mes régles iptables
mais je pense qu'avec les conseils que l'on m'a donnés, je
me débrouillerai.
Voilà le genre de script iptables que j'ai fini par obtenir.
Ce script (copié ci-dessous) est indiqué en post-up au niveau
de la dernière interface configurée dans le fichier
/etc/network/interfaces de l'hôte qui est un routeur/pare-feu
NAT avec une interface LAN et une interface WAN (indiquées dans
le script). L'hôte fait serveur DNS (via un forwarding), serveur
DHCP au niveau du LAN, serveur de temps au niveau du LAN et il
fait serveur proxy pour le LAN via Squid3.
Ce script est censé forcer les hôtes qui se trouvent dans
le LAN à passer par le proxy Squid3 pour faire du Web.
Je trouve que ce n'est pas si facile que ça de faire en
sorte que les règles iptables fassent exactement ce que l'on
veut qu'elles fassent et je serais très intéressé si vous
avez des remarques sur le script ci-dessous. Peut-être ne
fait-il pas exactement ce que je veux et peut-être même
que j'ai laissé sans m'en rendre compte des trous béants.
Si vous avez des remarques, suggestions etc. je suis
preneur.
Clairement il va falloir que je potasse mes régles iptables mais je pense qu'avec les conseils que l'on m'a donnés, je me débrouillerai.
Voilà le genre de script iptables que j'ai fini par obtenir. Ce script (copié ci-dessous) est indiqué en post-up au niveau de la dernière interface configurée dans le fichier /etc/network/interfaces de l'hôte qui est un routeur/pare-feu NAT avec une interface LAN et une interface WAN (indiquées dans le script). L'hôte fait serveur DNS (via un forwarding), serveur DHCP au niveau du LAN, serveur de temps au niveau du LAN et il fait serveur proxy pour le LAN via Squid3.
Ce script est censé forcer les hôtes qui se trouvent dans le LAN à passer par le proxy Squid3 pour faire du Web. Je trouve que ce n'est pas si facile que ça de faire en sorte que les règles iptables fassent exactement ce que l'on veut qu'elles fassent et je serais très intéressé si vous avez des remarques sur le script ci-dessous. Peut-être ne fait-il pas exactement ce que je veux et peut-être même que j'ai laissé sans m'en rendre compte des trous béants. Si vous avez des remarques, suggestions etc. je suis preneur.
