BARBAROUX BTS SIO SISR

Julie

Compte rendu du chapitre 13 : Serveur mandataire et proxy transparent (http et https)

J’installe le paquetage Squid sur le serveur CS4 :

Sur la station UD2, je paramétre, en configuration manuelle, le navigateur Firefox afin qu’il utilise le

proxy :

J’essaye ensuite d’ouvrir une page Internet mais cela ne marche pas car Squid a un comportement de

blocage par défaut suite à son installation :

Effectue donc une sauvegarde du fichier de configuration /etc/squid/squid.conf

3. Configuration du contrôle d’accès.

J’incère une acl et en supprime d’autre. J’autorise ensuite le réseau local à effectuer des requêtes

http via le proxy en ajoutant une directive http_access au-dessus des autres http_access

J’active et démarre le service Squid puis je vérifie son état :

Je vérifie aussi que le serveur Squid écoute sur le port 3128 :

Je constate alors que l’ouverture d’une page Internet est désormais possible depuis la station UD2 :

4. Contrôle d’accès suivant un horaire particulier.

Je définie alors une ACL afin que les stations du réseau local ne puissent accéder à Internet que du

lundi au vendredi au sein d’une plage horaire précise. Je modifie en conséquence la directive

http_access.

Je relance alors le service Squid et vérifie son état :

On constate que l’acces a internet depuis UD2 fonctionne :

Cependant, si j’enlève le lundi (jours au quel je fais le TP) On conste que je n’ai plus accès à internet :

Je définis alors une plage horaire pour le matin et une autre pour l’après-midi

Je relance alors le services :

On constate que je peux accéder a internet depuis UD2 :

Cependant si je change les horaire, je ne peux plus y accéder :

5. Filtrage des sites internet avec SquidGuard.

J’nstalle le paquetage SquidGuard :

Je crée le répertoire proxy ainsi que ses sous-dossiers html et logs dans /var/www/ :

La page par défaut de votre serveur apache figure dans le répertoire suivant :

Je copie la page /usr/share/httpd/noindex/index.html.en-US dans /var/www/proxy/html/ tout en la

renommant index.html puis je lui attribue le répertoire proxy au user:group apache et modifie les

permissions :

Je crée les répertoires sites-available et sites-enabled :

Je crée le fichier avertissement.conf du VirtualHost proxy dans le répertoire sites-available :

J’ajoute à la fin du fichier de configuration d’apache les deux dernières lignes indiquées ci-dessous

afin qu’Apache soit configuré pour appeler le contenu du répertoire sites-enabled au démarrage du

processus :

J’active alors le VirtualHost proxy en créant dans le répertoire sites-enabled, un lien symbolique

pointant vers le fichier avertissement.conf du répertoire sites-available puis je redémarre le service

Apache, ce qui ne fonctionne pas.

Comme le redémarrage a échoué, j’apporte la modification suivante concernant SELinux :

Puis je relance le service :

Je modifie la page index.html que j’ai placée dans le répertoire /var/www/proxy/html/

Je crée, dans le fichier /var/cache/bind/db.sio-exupery.fr du serveur DNS DS2, l’enregistrement de

type CNAME associé au VirtualHost proxy afin de permettre la conversion en adresse ip de l’url

http://proxy.sio-exupery.fr :

Depuis le navigateur d’UD2, je saisis l’url http://proxy.sio-exupery.fr afin de vérifier le bon affichage

de la page index.html associée au VirtualHost proxy :

J’installe le paquet wget :

Je récupère alors la blacklist mise à jour régulièrement par l’université de Toulouse :

La commande tar n’est pas disponible. J’installe donc le paquet nécessaire :

Je décompresse et extrait le contenue de l’archive :

Je supprime l’archive figurant dans le répertoire /var/squidGuard depuis l’installation de squidGuard

et y déplace le répertoire blacklists o

Je consulte le contenu du répertoire /var/squidGuard/blacklists :

Je consulte le contenu du répertoire /var/squidGuard/blacklists/webmail :

Je consulte le contenu du fichier domains :

J’ajoute dans le fichier /etc/squid/squid.conf les lignes pour rediriger Squid vers SquidGuard et pour

indiquer le nombre d’instances SquidGuard pouvant être lancées

J’effectue une copie du fichier de configuration de squidGuard :

Je modifie l’horaire de fin dans le fichier de configuration de SquidGuard :

Je définis le réseau concerné par le filtrage :

Je définis des destinations interdites (games, webmail, adult, agressif et drogue) :

Je définis aussi les règles d’accès ainsi qu’une redirection vers la page index.html figurant dans le

répertoire associé au VirtualHost proxy

SquidGuard utilise des bases de données au format Berkeley. Je dois donc la construir:

J’attribue l’ensemble des données de la liste noire à l’utilisateur squid et au groupe du même nom

Je redémarre le service Squid :

Je teste depuis UD2 l’accès aux sites http://www.jeux.com et https://www.laposte.net :

6. Modification des règles de la chaîne FORWARD du pare-feu.

J’autorise les flux provenant de CS4 à destination de la DMZ ainsi que le retour pour les

communications initiées par CS4.

J’interdis tout trafic direct entre Internet et le réseau interne afin d’obliger le passage par le proxy

CS4 (port 3128)

Je lance le script parefeu.sh. Teste, depuis UD2, l’accès à http://www.sio-exupery.fr,

https://www.google.fr et http://www.jeux.fr.

7. Configuration d’un proxy transparent http et https.

7.1. Interception et analyse des flux https : fonctionnalité SSL-Bump

Je vérifie la présence des options nécessaires pour filtrage https/SSL :

7.3. Configuration du pare-feu

J’ajoute les deux règles suivantes au script parefeu.sh afin de rediriger d’une part, les requêtes http

arrivant sur l’interface LAN à destination du port 80 vers le port 3128 du serveur proxy et d’autre

part, les requêtes https vers le port 3129 :

Je relance le script parefeu.sh.

7.4. Création d’un certificat racine

Je crée à la fois la paire de clef ainsi que le certificat :

Pour exporter le certificat d'autorité racine sans la clé privée, je crée un certificat encodé en DER que

l’on importera dans le navigateur d’UD2 :

7.5. Configuration du navigateur du client UD2

Sur la station UD2, je supprime la configuration manuelle du proxy du navigateur Firefox :

Importez le certificat racine dans le magasin des certificats du navigateur :

7.6. Modification du fichier de configuration de Squid

Je mets en place la fonctionnalité SSL-Bump dans le fichier /etc/squid/squid.conf afin de permettre

l’interception des flux http et HTTPS ainsi que la création à la volée de certificats SSL dynamiques qui

seront présentés au navigateur :

J’ai finalement changé les ligne du SSL dump après m’être aperçus que mon flag était obsolète :

7.7. Initialisation du cache qui contiendra les certificats TLS créés à la volée

Il sera nécessaire de télécharger le paquet policycoreutils-python-utils pour pouvoir utiliser la

commande semanage.

Je teste http://www.sio-exupery.fr, https://secu.sio-exupery.fr, https://www.laposte.net,

http://www.jeux.com et https://www.google.fr.

Je vérifie la présence des certificats SSL dynamiques créés à la volée dans le répertoire

/var/lib/squid/ssl_db/certs/ :

8. Redirection des requêtes http, https et DNS arrivant sur l’interface WAN de

CS4.

J’ajoute les règles suivantes au script parefeu.sh :

Je relance alors le script parefeu.sh et teste la redirection depuis le navigateur de votre station

physique en saisissant l’adresse IP que j’avais avez affectée à l’interface WAN du routeur pare-feu

CS4 :